AD-A083  759  AIR  FORCE  MAINTENANCE  AND  SUPPLY  MANAGEMENT  ENGINEER I— ETC  F/G  9/2 
LCOM  II  SIMULATION  SOFTWARE  USERS  REFERENCE  GUIDE* (U) 

OCT  79  W  F  DRAKE*  R  C  REISS 

UNCLASSIFIED  AFMSMET-78-5. 1  _ XL 

•  • 

I  OF  5 
^083  759 


LCOM  II 


Simulation  Software 
Users  Reference  Guide 
12  Oct  79 


AFMSMET  Report  78-5.1 
William  F.  Drake  III 

AND 

Lt  Raymond  C.  Reiss 


o 


VC*  A 


MANAGEMENT  ENGINEERING 


fmcmmT  is  best  quaiitt  m-crrcma 

X>PY  FURNISHED  TO  DDC  CONTAINED  A 
I  FI  CANT  NUMBER  OF  PAGES  VUIOU  DO  90t  * 
ODUCX  LEGIBLY* 


DISCLAIMER  NOTICE 


THIS  DOCUMENT  IS  BEST  QUALITY 
PRACTICABLE.  THE  COPY  FURNISHED 
TO  DTIC  CONTAINED  A  SIGNIFICANT 
NUMBER  OF  PAGES  WHICH  DO  NOT 
REPRODUCE  LEGIBLY. 


S i mulat i on  ^Software 
sers  Reference  Guide 


>  -  ■  ■  v-  -  -  -  h  .  ‘.r-  ■  ') 

■ 


ABSTRACT 


The  Logistics  Composite  (LCOM  II)  simulation  software  is  a  composite  of  individual  programs  or 
modules  written  in  SIMSCRIPT  n  which  communicate  directly  with  each  other  and  function  as  a  unit. 
This  software  was  designed  to  apply  simulation  to  studies  concerning  Air  Force  base  level  functions, 
e.g.  operations,  maintenance,  and  supply.  Through  simulation  the  impact  of  the  availability  of  all 
types  of  support  resources  on  the  operational  status  of  a  weapon  system  can  be  assessed.  The  LCOM  II 
software  together  with  the  data  representing  a  weapon  system's  environment  form  study  models  that 
permit  the  analysis  of  weapon  system  support  >equirements. 

The  LCOM  II  simulation  software  is  composed  of  4  distinct  modules;  the  Input  Module  that  processes 
the  data,  the  Main  Module  that  conducts  the  simulation,  the  Restart  Module,  and  the  Post  Processor 
Module  that  includes  several  individual  post  processor  programs  providing  post  simulation  analysis  and 
data  displays. 

All  modules  of  the  LCOM  II  simulation  software  are  described  in  detail,  their  data  input  requirements 
specified,  and  application  methodology  and  procedures  are  prescribed.  All  output  products  are 
described  in  detail,  and  a  step-by-step  approach  for  preparing  the  input  forms  is  discussed. 


SIMSCRIPT  II  designed  to  apply  simulation  to  studies  concerning  Air  Force  base  level  functions.  The 
original  "Logistics  Composite  Model  User  Reference  Guide,"  AFLC  Report  70-1,  was  published  in 
January  1970.  A  "Logistics  Composite  Model  User  Reference  Guide  Update,"  AFLC/ADDR  Report  74- 
1,  was  published  in  November  1974.  Both  documents  were  placed  in  the  Defense  Documentation 
Center,  Cameron  Station,  Virginia,  under  the  respective  assigned  numbers  AD-7Q3-328  and  AD-A003- 
211.  Those  two  documents  describe  the  original  LCOM  programs  which  were  written  in  SIMSCRIPT  I. 
Updn  conversion  of  the  software  to  SIMSCRIPT  II  and  completion  of  major  enhancements,  the  "LCOM 
II  Standard  System  Version  1.2  User  Documentation"  was  published  on  15  November  1977  to  update  the 
two  previous  documents  and  establish  the  preliminary  LCOM  II  user  documentation. 

The  "LCOM  II  Simulation  Software  Users  Reference  Guide",  AFMSMET  Report  78-1,  was  published  on 

I  May  1978  and  completely  described  the  LCOM  II  simulation  software  Version  2.0.  It  combined 
information  from  all  three  previous  documents,  an  LCOM  II  briefing,  and  applicable  portions  of  LCOM 

II  program  documentation.  It  superceded  all  previously  published  LCOM  I  and  LCOM  II  user  reference  j 
documentation. 

AFMSMET  Report  78-5  is  essentially  a  significant  update  to  Report  78-1  and  describes  the  LCOM  II 
Version  3.5  released  for  Air  Force  use  in  December  1978.  This  report  describes  all  new  featires  and 
enhancements,  changes  necessary  for  system  standardization,  and  a  new  sample  problem,  that 
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1.  INTRODUCTION 


A.  Background 

The  environment  of  increasingly  complex  weapon  systems  and  equally  complex  support  systems  has 
created  a  requirement  for  improved  scientific  tools  to  assist  in  the  evaluation  of  these  systems.  A 
technique  was  needed  that  permitted  a  systematic  approach  to  analysis  of  the  support  requirements  for 
complete  weapon  systems.  Computer  simulation  was  selected  as  the  best  means  of  analyzing  support 
systems  on  an  item-by-item  basis  in  terms  of  their  effect  on  operating  performance.  Although  the 
initial  interest  was  in  logistics  support  areas,  simulation  further  permitted  an  across  the  board  analysis 
of  other  types  of  support  resources,  i.e.,  men,  test  equipment,  etc. 

Logistics  Composite  (LCOM)  software  employs  simulation  to  analyze  the  impact  of  all  types  of  support 
resource  shortages  on  the  operational  status  of  a  weapon  system.  The  LCOM  software  together  with 
the  data  representing  a  weapon  systems  environment  form  study  models  that  permit  the  analysis  of  the 
weapon  systems  support  requirements. 

Development  of  LCOM  Simulation  Software  began  in  November  1966  as  a  joint  effort  between  the  Air 
Force  Logistics  Command  (AFLC)  and  the  Rand  Corporation,  Santa  Monica,  California.  The  software 
development  was  transferred  to  AFLC  in  1967,  where  it  was  completed  and  implemented  on  the 
UNIVAC  1107.  The  foremost  consideration  in  LCOM  software  development  was  to  efficiently  utilize 
computers  to  address  an  optimized  support  resource  environment.  Attainment  of  this  goal  is  a  primary 
reason  for  the  continually  expanding  use  of  the  LCOM  system. 

Use  of  the  LCOM  Simulation  Software  in  areas  other  than  logistics  was  begun  at  the  Tactical  Air 
Command  (TAC)  in  1971.  This  introduced  the  manpower  community  to  a  tool  that  provided  a  significant 
aid  in  the  development  of  Air  Force  aircraft  maintenance  manning  standards.  Also,  LCOM  simulations 
allowed  wartime  manning  standards  to  be  evaluated  in  a  manner  not  possible  before. 

Subsequently,  the  Air  Force  Human  Resource  Lab  (AFHRL)  and  the  Air  Force  Systems  Command 
(AFSC)  began  in  1972  to  use  LCOM  Simulation  Software  in  the  area  of  weapon  system  procirernent. 
With  Simulation  Software,  they  were  better  able  to  consider  the  impact  of  trade-offs  between  the 
various  types  of  resources  prior  to  and  during  the  early  weapon  system  acquisition.  The  impact  of 
decisions  at  this  point  in  the  life  of  a  weapon  system  is  a  key  factor  in  reducing  total  weapon  system 
cost. 

LCOM  Simulation  Software  use  was  further  extended  to  the  weapon  system  test  and  evaluation  phase 
thru  the  efforts  of  the  Air  Force  Test  and  Evaluation  Center  (AFTEC)  beginning  in  1974. 

With  the  role  of  LCOM  Simulation  Software  expanding  there  was  an  increased  requirement  for 
improvement  in  the  software  and  for  a  single  point  to  control  its  maintenance.  The  i ni ti al  step  in  that 
direction  was  the  establishment  of  an  LCOM  Steering  Group  consisting  of  all  major  users.  Subsequently, 
major  improvements  were  made  during  a  contractual  conversion  of  the  LCOM  Simulation  Software  from 
the  SIMSCRIPT  I  to  the  SIMSCRIPT  II  programming  language.  This  effort  was  sponsored  by  USAF/LG 
between  March  1975  and  Tune  1977.  This  conversion  improved  the  efficiency  and  added  many  new  user 
features,  resulting  in  the  software  now  called  LCOM  11.  The  software  was  implemented  on  both  the 
Honeywell  600/6000  and  CDC  6600/7600  computers. 

The  Air  Force  Maintenance  and  Supply  Management  Engineering  Team  (AFMSMET)  located  at  Wright- 
Patterson  Air  Force  Base  was  assigned  the  role  of  system  caretaker  in  1977  and  is  responsible  for  the 
Air  Force  wide  implementation  and  manpower  usage  of  software. 

In  the  latter  part  of  1978  the  LCOM  II  software  was  implemented  on  the  ITEL  AS/5  (IBM  360 
compatible)  computer.  In  conjunction  with  this  reimplementation  the  software  was  standardized  where 
possible  across  the  Honeywell  600/6000,  CDC  6600/7600  and  the  ITEL  AS/5  computers.  Concurrently, 
improvements  were  made  in  the  softwares,  efficiency  and  memory  requirements. 
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B.  Role  of  Simulation 


The  utilization  of  support  resources  (personnel,  equipment,  spare  parts,  etc.)  and  the  impact  of  t»>eir 
shortage  on  the  operational  status  of  the  weapon  system  is  a  function  of  probabilistic  occurrences. 
Simulation  is  the  most  direct  approach  for  considering  the  stochastic  nature  of  the  support  processes  in 
determining  a  best  mix  of  resource  levels  that  would  effectively  support  a  given  weapon  system  flying 
program. 

For  evaluation  analysis,  a  simulation  model  can  compare  the  benefits  to  be  realized  from  alternative 
support  postures  in  terms  of  resources  and  repair  capability.  This  requires  an  established  scenario  and 
support  posture  with  subsequent  trials  varying  one  or  more  factors  under  consideration.  For  example, 
given  an  operational  scenario  and  resource  postire,  the  flying  prop-am  can  be  successively  incremented 
with  typical  or  random  flying  schedules  until  a  prescribed  level  of  operation  effectiveness  can  no  longer 
he  supported.  This  method  can  be  employed  to  approximate  the  system  "break- point,"  that  is,  the  level 
of  operations  that  is  the  limit  of  supportability.  Conversely,  the  flying  schedule  may  be  held  fixed  and 
vhe  resource  posture  can  be  successively  altered  until  desired  operational  effectiveness  is  obtained. 
Similar  evaluations  can  be  made  by  varying  other  factors  of  the  overall  support  system. 

Simulation  is  an  effective  tool  for  system  analysis.  It  cannot,  however,  be  used  without  caution.  Any 
decision  maker  will  require  sufficient  facts  on  which  to  base  a  decision.  A  simulation  model  does  not 
refuse  to  give  answers  simply  because  all  the  factors  are  not  present  or  are  invalid  for  the  analysis 
being  attempted.  The  user  of  simulation  models  must  be  confident  that  all  the  relevant  factors  are 
present  in  his  input,  that  there  is  a  reasonable  degree  of  accuracy  and  representation,  and  that  his 
abstraction  of  factors  does  not  bias  the  results.  Where  there  is  uncertainty,  the  model  can  serve  to  test 
the  sensitivity  of  the  results  to  the  abstractions.  If  the  results  are  not  sensitive,  the  user  can  be  assured 
that  his  estimates  will  not  seriously  bias  his  results. 

C.  The  LCOM  Simulation  Software  and  Weapon  System  Models 

Numerous  simulation  models  have  been  developed  that  address  the  area  of  aircraft  operations, 
maintenance  and  supply.  These  models  have,  for  the  most  part,  been  problem  oriented  in  that  they  did 
ry.r  have  an  appropriate  balance  in  the  representation  of  the  environment.  Other  attempts  have 
successfully  achieved  a  better  balance  but  not  in  a  single  model.  Maximum  flexibility  of  representation 
's  required  in  a  support  resource  model. 

The  LCOM  Simulation  Software  attempts  to  leave  maximum  control  over  the  detail  of  data 
repr  esentation  up  to  the  user,  so  that  he  may  design  his  own  model  environment  and  the  balance  he 
believes  to  be  necessary  for  his  problem.  The  software  is  designed  to  process  spares  on  an  item-by-item 
basis  or  where  the  user  is  more  concerned  with  operations,  permits  him  to  abstract  the  support  system 
and  treat  an  aggregate  of  spares  in  the  form  of  sub-systems.  Therefore,  the  weapon  system  models 
developed  can  more  readily  be  tailored  to  the  requirements  of  the  study  being  conducted. 

With  such  user  control  of  the  environment  description,  various  weapon  system  models  can  be  developed 
using  the  same  LCOM  Simulation  Software.  The  commonality  of  software  inputs,  simulation  techniques 
used,  and  output  products  provided,  contribute  to  the  standardization  of  study  techniques  and  data 
analysis. 

In  summary,  the  LCOM  Simulation  Software  is  designed  to  more  adequately  represent  aircraft 
operations,  the  resulting  demands  for  support  resources  and  the  interactions  involved  in  the  demand 
process,  within  the  framework  of  a  single  weapon  system  model  operable  on  current  generation 
computers. 


D.  Validation  Retirements 

Once  designed  and  developed,  a  weapon  system  model  must  be  validated  prior  to  acceptance  of 
simulation  results.  This  process  of  validation  is  not  a  simple  one  to  define.  Historical  and  statistical 
validation  are  two  important  methods. 

Historical  validation  is  the  comparison  of  simulation  results  with  the  real  world  results  from  the  weapon 
system  being  simulated.  This  is  not  always  possible  when  dealing  with  situations  not  readily  observable, 
such  as  of  a  new  weapon  system  or  of  wartime  operations.  However,  historical  validation  of  peacetime 
conditions  can  and  have  been  accomplished.  With  these  as  a  basis,  extrapolations  to  other  conditions 
can  usually  be  made  with  acceptable  results. 

Since  numerous  historical  validations  have  been  accomplished  in  the  past  involving  several  different 
weapon  systems,  the  basic  LCOM  Simulation  Software  has,  in  effect,  been  through  a  vigorous  validation. 
With  each  additional  historical  validation,  the  solidarity  of  the  software  logic  is  again  reverified. 

In  addition,  over  the  past  several  years  many  statistical  validations  of  the  weapon  system  models 
developed  with  LCOM  Simulation  Software  have  proved  the  stability  and  accuracy  of  the  software  logic 
itself.  The  outputs  have  been  analyzed  and  compared  through  application  of  spectral  density  analysis. 
Other  standard  statistical  techniques  have  also  been  applied  to  the  software  results.  No  outstanding 
faults  were  evidenced. 

Finally,  model  validation  has  been  aided  through  the  development  of  quality  control  procedures  on 
model  development  and  the  use  of  graphic  and  statistical  evaluation  of  data  inputs. 

E.  Software  Stability 

Throughout  the  years  of  LCOM  Simulation  Software  usage  the  basic  philosophy  has  not  changed.  The 
methods  used  to  establish  and  process  the  users  environment,  the  aircraft  operation  control  featire,  and 
the  method  of  support  resource  interaction  have  all  remained  very  stable.  Necessary  improvements  on 
these  and  other  salient  features  of  the  software  have  occirred  and  software  optimizations  have  been 
accomplished. 


Improvements  to  the  LCOM  simulation  software,  have  always  considered  upward  data  compatability, 
where  possible,  as  a  prerequisite.  Many  of  the  input  data  forms  have  not  been  changed  or  only  slightly 
modified.  However,  some  additional  forms  have  evolved  during  the  improvement  process. 


H.  GENERAL  DESCRIPTION 


A.  The  LCOM  11  System 

The  LCOM  II  Simulation  Software  described  herein  can  be  applied  directly  to  the  development  of 
weapon  system  models  without  the  requirement  for  any  additional  programs.  However,  continual  use 
of  the  software  over  the  past  few  years  has  resulted  in  the  development  of  auxiliary  support 
programs.  The  Simulation  Software  is  the  major  component  of  a  total  system  tef erred  to  as  the 
I  COM  II  System.  Figure  2-1  shows  the  system’s  structure  which  is  composed  of  the  two  major  parts; 
the  LOOM  II  Simulation  Software  and  the  LCOM  II  Auxiliary  Programs.  The  LCOM  II  Auxiliary 
Programs  are  valuable  aids  in  data  development  and  analysis.  However,  they  are  not  required  in 
order  to  develop  a  weapon  system  model  with  the  simulation  software  or  to  conduct  a  simulation 
study  using  the  software.  The  user  documentation  of  these  auxiliary  programs  will  not  be  included  in 
this  document,  but  will  be  published  under  separate  cover  since  various  organizations  have  developed 
and  documented  their  own  auxiliary  programs. 

B.  Simulation  Software  Structure. 

The  LCOM  II  Simulation  Software  was  developed  as  a  composite  of  individual  programs  or  modules 
which  communicate  directly  with  each  other  and  function  as  a  unit.  As  seen  in  Figrre  2-1,  the 
software  is  composed  of  four  modules;  the  Input  Module,  Main  Module,  Post  Processor  Module,  and 
Restart  Module.  The  specific  functions  of  the  total  simulation  process  included  in  each  module  is 
also  shown  on  Figure  2-1.  The  basic  communication  and  interfaces  between  the  modules  is  reflected 
in  Figure  2-2.  A  more  detailed  view  of  these  and  other  user  interfaces  is  described  in  Appendix  A. 
This  appendix  describes  the  current  computer  implementations,  proper  job  control  language 
requirements,  and  test  case  results  as  an  aid  in  implementation  and  checkout  of  the  software. 

Figure  2-2  shows  the  passage  of  two  data  files  from  the  Input  Module  to  the  Main  Module.  These 
files  are  called  the  Initialization  file  (contains  the  environment  description)  and  the  Exogenous  file 
(contains  the  mission,  sortie  and  activity  processing  requirements). 

The  Main  Module  directs  a  single  file  of  detailed  transaction  data  to  the  Post  Processor  Module. 
However,  data  placed  on  this  file  must  have  first  been  requested  by  the  user.  It  is  not  automatically 
generated.  The  Main  Module  produces  a  restart  checkpoint  tape  to  pass  to  the  Restart  Module.  It 
also  must  be  user  requested  and  operated  only  on  the  Honeywell  600/6000  computers. 

1.  Input  Module  Functions.  The  primary  function  of  the  Input  Module  is  twofold: 

a.  It  is  a  translator  that  reduces  and  reformats  the  data  provided  by  users  on  easy  to  use 
input  forms  into  a  data  structure  that  is  suitable  for  use  by  the  Main  Module.  This  is  called 
Ini  tialization. 


b.  It  is  a  sortie  generator  permitting  the  user,  by  exercising  available  options,  to  specify 
a  flying  and  activity  program  that  will  exercise  the  support  system  in  the  Main  Module.  The  flying 
program  is  defined  in  terms  of  missions  and/or  activities  requiring  specific  types  and  quantities  of 
aircraft  or  non-aircraft  resources. 

The  Input  Module  will  edit  the  input  data  and  provide  diagnostics  where  inconsistencies  are  found  in 
the  data.  In  some  cases  where  ambiguities  are  found,  assumptions  will  be  made  as  to  what  the  user 
intended  to  insert  and  a  message  will  be  provided  giving  what  was  found  and  what  assumption  was 
made.  This  feature  prevents  loss  of  an  Input  Module  run  when  the  assumption  might  be  acceptable. 
In  more  serious  cases,  where  such  an  assumption  cannot  be  made,  the  execution  is  terminated  after 
ail  data  has  been  edited.  These  checks  or  edits  are  by  no  means  exhaustive  but  cover  a  wide  range 
of  possibile  errors  and  are  a  valuable  feature  of  the  Input  Module.  However,  the  logical  intent  of  a 
user  is  one  area  that  cannot  easily  be  checked  or  any  assumption  made. 
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2.  Main  Module  Factions, 


The  Main  Module  conducts  the  actual  simulation  based  upon  the  data  provided.  The  logic  in  this 
software,  together  with  the  data  logic,  permits  the  simulation  of  a  support  response  to  the  flying 
schedule.  This  response  includes  generating  weapon  system  malfunctions  or  parts  failures 
corresponding  to  those  found  in  the  reliability  data,  processing  the  tasks  that  must  be  accomplished 
for  their  correction,  demanding  the  resources  that  are  required  to  accomplish  these  tasks,  and 
controlling  the  resultant  interactions  due  to  resource  non-availability  in  the  demand  process. 
Resources  may  be  described  as  any  physical  portion  of  the  support  system,  e.g.,  parts,  men, 
equipment,  or  anything  that  has  a  unit  measure  and  is  required  in  the  performance  of  a  task. 
Aircraft  are  considered  as  resources.  Most  parts  are  considered  as  recoverable  items  in  that  they 
are  replenished  with  a  one-for-one  replacement  inventory  policy;  i.e.,  when  a  failed  part  is  classified 
as  non-  reparable  and  sent  to  another  repair  facility,  one  jerviceable  like  item  is  returned  to  stock 
after  an  order-and-shipping  time  delay.  This  one-far-one  policy  is  not  a  software  assumption  but 
must  be  networked  by  the  user.  Consumable,  or  non-recover  able,  parts  may  also  be  included  without 
a  batch  replenishment  policy. 

3.  Post  Processor  Module  Function.  This  maduile  accomplishes  a  post-simulation  analysis 
function.  During  simulation,  it  is  possible  to  generate  a  large  amount  of  detailed  data  representing 
simulation  results.  The  data  may  then  be  combined,  summarized,  and  consolidated  into  output 
reports  of  various  kinds.  In  many  large  simulation  models,  data  generated  during  the  simulation  are 
processed  afterward  by  a  separate  program  called  a  post  processor  to  obtain  the  summary  reports. 
In  LCOM  II,  the  Main  Module  itself  produces  a  Performance  Summary  Report  (PSR)  as  it  operates. 
However,  the  separate  Post  Processor  Module  produces  several  ancillary  products.  The  PSR  and 
other  reports  produced  during  the  simulation  generally  reflect  the  behavior  and  status  of  the 
simulated  environment  during  discre.e  time  intervals  or  at  specific  points  in  time  in  accordance  with 
the  reporting  interval.  To  obtain  results  over  the  entire  simulation,  a  number  of  output  records  must 
be  inspected.  This  is  the  function  of  the  Post  Processor  Module  in  LCOM  II;  to  develop  single 
products  displaying  selected  summary  statistics  covering  the  entire  simulation.  In  effect,  it 
consolidates  the  periodic  reports  produced  during  tie  simula'ion.  It  also  produces  aircraft, 
manpower,  mission,  sortie,  and  part  status  information  as  a  function  of  simulated  time  rather  than 
at  specific  points  in  time. 


Restart  Module  Functions, 


This  module  provides  the  capability  to  restore  from  a  tape  (produced  by  the  Main  Module  during 
simulation)  the  entire  contents  of  memory  at  the  point  in  simulated  time  a  memory  dump  was  taken, 
and  return  to  a  fixed  point  in  memory  which  will  cause  a  restart  of  the  simulation.  Included  in  this 
is  the  complete  repositioning  of  all  files  except  the  printer  file  prior  to  restarting.  This  module  is 
only  applicable  on  the  Honeywell  600/6000  computers. 


The  LCOM  II  Simulation  sof  tware  is  capable  of  producing  a  great  deal  of  data  in  varying  levels  of 
detail.  The  Main  Moduile  in  particular  could  produce  detailed  data  representing  a  full  scale 
accounting  of  sill  missions,  jobs,  resources,  and  resource  utilization  over  simulated  time;  or  such  data 
could  be  combined  or  aggregated  in  almost  an  infinite  number  of  ways.  It  is  possible  to  literally 
flood  a  user  of  the  software  with  all  kinds  of  such  data. 


However,  a  major  desigi  criterion  for  the  Main  Moduile  was  to  keep  the  output  reports  to  a  necessary 
minimum  and  confined  to  agg’egate  performance  statistics  within  preselected  system,  sub-system, 
specialty  code,  or  equipment  groupings.  Care  should  be  taken  by  the  user  in  selecting  these 
groupings  to  assure  that  the  statistics  collected  within  them  represent  meaningful  averages  in  terms 
of  the  sample  sizes  and  the  length  of  time  in  which  the  simulated  resuilts  are  collected.  If  too  small 
a  sample  size  or  insufficient  simulation  time  is  used,  the  statistics  collected  couild  reflect  the  results 
of  unusual  random  chaws  made  by  the  computer. 


For  these  reasons,  only  the  main  PSR  reports  are  automatically  produced  for  the  user.  Other  user 
reports  are  available  on  both  a  specific  time  basis  ar.d  a  time  aggregation  basis.  These  reports  must 
be  selected  and  scheduled  by  the  user.  Some  additional  programmer  reports  are  also  selectable,  but 
in  these  cases  the  volume  of  output  is  often  significant.  Selection  of  these  user  and  programmer 
reports  should  be  based  upon  the  need  for  the  data  to  be  produced.  Such  a  need  might  be  when  a 
particular  summary  statistic  is  out  of  line,  or  inconsistent  with  other  results.  In  such  a  case, 
detailed  data  may  provide  clues  as  to  now  it  happened  and  may  point  out  input  data  errors  or 
malfunctions. 

Each  of  the  modules  contained  in  the  LCOM  II  Simulation  Software  ha',  its  own  set  of  output  reports 
which  are  described  in  the  appropriate  chapters.  In  each  case,  the  report  is  identified  as  to  whether 
it  is  automatically  produced  or  requirts  a  user  to  explicitly  request  its  output. 

C.  Basic  Philosophy  of  Logic  Input. 

In  order  to  obtain  the  necessary  versatility  of  being  able  to  apply  LC  OM  II  to  a  wide  range  of  weapon 
systems,  a  new  concept  in  model  design  was  used.  That  concept  was  to  have  the  majority  of  the 
simulation  logic  provided  externally  in  the  data  (between  80%  and  90%),  rather  than  have  it  as  an 
inherent  fixed  part  of  the  software  itself.  To  imp'ement  this  "User  Provided  Logic"  concept,  a 
network  technique  was  used.  This  network  approach  permits  a  description  of  the  sequence  of 
necessary  tasks  or  events  required  to  complete  the  processing  of  the  particular  item  or  activity 
being  studied.  This  users  guide  will  explain  how  this  network  technique  is  applied  and  how  it 
provides  the  necessary  flexibility  for  describing  the  logic  of  an  AF  base  environment,  regardless  of 
the  weapon  system  involved. 

D.  Internal  Software  Functional  Logic. 


Figure  2-3  represents  the  basic  flow  logic  within  the  Main  Module.  This  is  in  terms  of  the 
relationship  of  the  various  key  network  segments.  During  the  simulation  process,  an  attempt  is 
made  to  complete  each  mission  requested.  This  is  done  by  obtaining  the  needed  aircraft  from  a 
ready  pool  and  beginning  their  processing  through  a  set  of  uset  defined  pre-sortie  tasks.  This  is 
started  at  the  time  the  mission  is  requested.  A  take-off  and  cancellation  time  is  also  established  by 
the  mission  request.  Once  the  required  aircraft  complete  the  set  of  re-sortie  tasks  and  the  take¬ 
off  time  is  reached,  the  aircraft  begins  the  sortie  task  (flies  tlie  sortie).  Upon  completion  of  this 
task,  the  aircraft  must  undergo  the  defined  post-sortie  tasks.  When  completed,  the  aircraft  are 
returned  to  the  serviceable  pool.  The  time  to  cancel  will  be  utilized  only  if  insufficient  aircraft  are 
ready  to  fly  the  mission,  or  if  the  pre-sortie  tasks  cannot  be  completed  in  the  allotted  time. 

In  addition  to  this  basic  mission/sortie  timing  logic,  the  Main  Mo<  ule  contains  two  additional  areas 
of  built  in  logic.  One  is  the  network  processing  logic  that  permits  entry  into  a  piece  of  network  and 
insures  the  proper  processing  of  all  tasks  within  the  hetwork,  bcsed  upon  the  user  supplied  task 
selection  logic.  Upon  completion  of  any  portion  of  *he  network,  logical  processing  transfers  to  the 
next  portion  of  the  networks  as  defined  and  structured  in  the  data.  Finally,  the  statistic  collection 
logic  in  the  Main  Module  is  oriented  toward  the  logical  hierarchy  of  the  base  environment.  This  is 
the  only  reason  that  LCOM  II  is  a  base  model,  because  it  collects  base  type  statistics.  The 
remainder  of  the  logic  in  the  Main  Module  is  in  the  implementation  of  the  particular  features  which 
are  primarily  user  selectable  and  require  the  addition  of  extra  data. 

E.  User  Supplied  Logic  Networks. 

The  pre-sortie  and  post-sortie  blocks  in  Figure  2-3  represent  sections  of  logic  the  Main  Module 
processes.  These  are,  as  indicated,  user  supplied  logic  networks.  Pre-Sortie  networks  could  include 
tasks  such  as  preflight  checks,  weapons  loading,  etc.  Post-Sortie  tasks  might  include  fuel  service, 
post- flight  inspection,  unscheduled  and  scheduled  maintenance,  etc.  Tasks  within  these  networks 
will  define  the  resources  required  to  do  the  task,  priority  of  work  relative  to  other  defined 
maintenance,  and  their  relationship  to  succeeding  taste. 

The  detail  of  the  task  networks  txe  entirely  under  user  control  and  are  limited  only  by  the 
availability  of  data  and  computer  memory  required  to  process  tlv;  task  networks.  A  detailed 
description  of  network  construction  is  provided  in  Chapter  IV. 
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HI.  INPUT  MODULE 

A.  General  Description 

The  general  function  of  the  Input  Module  .s  to  translate  user  supplied  data  into  a  form  which  can  be 
used  by  the  Main  Module  of  the  LCC'M  II  Simulation  Software.  The  relationship  of  this  module  to  the 
Main  Module  was  depicted  in  Fig.  2—1. 

The  user  provides  the  data  that  describes  the  operating  environment  for  the  simulation  on  a  set  of  pre¬ 
printed  input  forms.  The  information  on  the  forms  is  then  transcribed  onto  punched  cards  or 
permanent  files  to  form  the  "input  data."  This  input  data  is  then  read  by  the  Inpuv  Module. 

The  Input  Module  performs  two  independent  functions:  (1)  The  portion  of  the  input  data  comprised  of  | 
all  forms  except  Form  20  is  edited  and  converted  irto  the  initial  conditions  file  generally  referred  to 
as  an  "Initialization".  At  the  same  time,  extensive  error  checking  is  performed  and  an  edited  listing  of 
the  input  data  is  printed.  This  listing  includes  diagnostic  messages  if  any,  notifying  the  user  of  input 
data  which  is  either  in  error,  has  been  omitted,  or  found  to  be  inconsistent  with  other  data.  (2)  The 
portion  of  the  input  data  comprised  of  the  Form  20s  is  edited  and  produce:  an  "exogenous  events  tape." 
This  tape  contains  all  mission  and  activity  requirements  by  type  and  time  of  day,  for  the  entire 
diration  of  the  simulation.  It  is  read  during  the  actual  simulation  and  is  the  means  by  which  external 
demands  are  imposed  on  the  simulated  system.  It  should  be  noted  that  these  two  portions  of  the  input 
data  deck  can  be  and  are  quite  often  run  separately. 

Reformatted  data  from  the  Input  Module  is  used  b;  the  Main  Module  and  Post  Processor  Module  which 
are  fully  described  in  Chapters  IV  and  V,  respectively.  The  input  data  requirements  for  each  module 
are  also  covered  in  these  chapters  while  the  specific  instructions  for  fiUing  out  each  of  the  input  forms 
are  described  in  Chapter  VIII. 

The  remainder  of  this  chapter  will  define  the  input  forms,  describe  certain  features  and  conventions 
which  are  common  to  all  input  forms,  and  describe  the  Initialization  and  the  Sortie  Generation 
processes. 

B.  Input  Forms 


The  Input  Module  uses  data  input  on  13  different  forms.  Each  form  has  a  specific  purpose  and  permits 
entry  of  common  types  of  data.  Some  of  the  forms  are  optiona.  in  that  they  are  not  required,  e.g. 
Form  15  empirical  distributions.  The  specific  user  options  will  be  further  explained  when  discussing 
the  particular  form  itself  in  Chapter  Vin.  All  the  forms  are  listed  in  Table  3-i  along  with  a  very  brief 
purpose. 
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Data  Type 
10 
11 
12 

13 

14 

15 


Table  3-1  Input  Forms 

Form  Name 

Performance  Summary  Report 
Task  Network 
Task  Definitions 
Resource  Definitions 
Failure  Clock  De crements 


Data  Types 
Purpose 

Defines  report  structure. 

Inputs  task  network. 

Defines  task  parameters. 

Defines  ell  resources  and  clocks. 
Defines  task/ clock  relationships. 
Inputs  empirical  distributions. 


Defines  authorizations  by  shift. 


16 


Distributions 

Shift  Change  Policies 


17 

Mission/ Activity  Entry  Points 

Defines  resources  entering  network 
and  required  configurations. 

18 

Priority  Specifications 

Inputs  priority  systems  parameters. 

20 

Sortie  Generation 

Inputs  mission/ activity  parameters. 

21 

Aircraft  Assignment  Search 

Patterns 

Defines  external  and  internal  con¬ 
figuration  search  sequence. 

22 

Internal  Equipment  Authorizations/ 
Changes 

Defines  internal  equipment,  their 
authorizations,  and  trigger  node 
effects. 

23 

Internal  Equipment  Croup  Definitions 

Defines  internal  equipment  groupings 
by  quantity. 

C.  Common  Input  Form  Features  -  See  Appendix  F  for  Form  Masters 

1.  Data  (Form)  Types  -  Header  Requirement 

Each  input  form  is  identified  by  a  "data  type"  in  columns  2  and  3  which  is  the  same  as  the  form 
number.  All  the  LCOM  II  forms  are  listed  in  Table  3-1.  When  preparing  a  data  set,  all  data  records  of 
a  similar  type  are  grouped  together.  Each  group  of  data  records  must  be  preceded  in  the  input  data  by 
a  header  record  which  has  the  same  data  type  in  columns  2  and  3.  The  remainder  of  the  header  record 
through  column  73  may  contain  any  information,  but  this  information  is  ignored  by  the  prop-am.  In  the 
records  following  the  header  record,  columns  2  ai  d  3  may  be  left  blank,  thereby  defaulting  the  card 
type  equal  to  the  preceding  card. 

2.  Control  Character 


Normally  the  first  column  of  each  record  in  the  input  data  is  blank,  but  can  at  the  user's  option,  serve 
as  a  printer  carriage  control.  These  characters  control  the  spacing  of  the  input  data  during  processing 
and  are  as  follows: 


Character  Meaning 

blank  Normal  spacing,  new  line  for  each  data  entry. 


0  Skip  one  line  before  printing  data. 

1  Eject  page  before  printing  data. 

3.  Naming  Conventions 


On  the  input  forms,  tasks,  resources,  clocks,  nodes,  missions  and  several  other  data  items  are 
identified  by  "names.’’  These  names  may  be  up  to  six  characters  in  length  and  may  consist  of  letters, 
numbers,  and  special  characters  ir  any  combination.  Imbedded  blanks  are  considered  to  be  part  of  the 
name,  but  leading  or  following  blanks  are  ignored.  Examples  of  typical  names  are:  RES21,  C5000, 
TOW,  RF-4C,  CLSPT. 

When  filling  out  the  input  forms,  tie  names  may  be  placed  anywhere  within  the  designated  field  (if  the 
name  is  less  than  six  characters).  The  program  will  automatically  left-justify  all  names.  Thus,  the 
names  "bbABCb"  and  "ABCbbb"  are  equivalent  where  b  designates  blank  spaces. 
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4.  Numerical  Data  Fields 


Numerical  fielcfa  are  flexible  as  to  the  types  of  data  which  will  be  accepted.  The  user  does  not  need  to 
concern  himself  with  integer  vs.  decimal  modes.  For  instance,  either  "5"  or  "5.0"  expresses  the  number 
five.  As  in  the  case  with  "names,"  numerical  data  may  be  placed  anywhere  within  the  designated 
fields. 

A  single  "K"  placed  anywhere  within  the  field  wilt  cause  the  value  to  be  multiplied  by  1000.  Two"K's" 
will  cause  the  value  to  be  multiplied  by  1,000,000.  This  featire  can  also  be  used  in  conjunction  with 
the  special  formats  described  below. 


cial  Formats 


Most  of  the  numerical  values  supplied  by  the  user  are  time  oriented.  Typical  examples  are  task 
duration,  sortie  lengths,  and  mean  time  between  failure.  Unless  otherwise  specified,  the  program  will 
automatically  assume  that  all  time  values  are  given  in  . tours  except  on  Forms  13  and  14  where 
decimals  or  days  are  assumed.  The  user  may  and  probably  should  override  this  feature  on  any  form  by 
inserting  any  of  the  following  characters  anywhere  within  the  field  in  question: 

Character  Meaning  Examples 


3D,  4.5D 
•J0M 

4.5H,  4KH 
4+00,  +15 
3+9+15,  4+19+ 
2W,  2.5W 
1Y,  1.25Y 


Time  expressed  in  days 
Time  expressed  in  minutes 
Time  expressed  in  hoirs 
Time  in  hours  am  minutes 
Time  in  days,  hours,  and  minutes 
Time  expressed  in  weeks 
Time  expressed  in  years 


6.  Distributions 


The  user  may  wish  to  express  certain  values,  such  as  task  durations  or  failure  rates,  as  a  time 
distribution  rather  than  as  a  single  time  value.  He  may  specify  the  use  of  a  standard  distribution 
directly  or  he  may  refer  to  an  empirical  distribution  which  he  has  difined. 

Standard.  When  a  standard  distribution  is  used,  the  type  of  dist-ibutior.  selected  is  entered  in 
the  column  labeled  D1ST.  The  type  selected  governs  the  statistical  meaning  of  the  data  entered  in  the 
columns  named  MEAN  and  VARIANCE.  The  available  standard  distributions  and  their  data 
requirements  are  shown  in  Table  3-2. 
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TA3LE  3-2  DISTRIBUTION  PARAMETERS 


DISTRIBUTION  DIST  MEAN 


VARIANCE 


NORMAL 

POISSON 

LOGNORMAL 

EXPONENTIAL 

BERNOLLI3 

CONSTANT 

ERLANG4 

WEIBUL5 

TRIANGULAR6 


N 

P 

L 

X 

A 

C 

E 

W 

T 


Statistical  Mean 
Statistical  Mean: 
Statistical  Mean: 
Statistical  Mean: 
Statistical  Mean1 
Statistical  Mean . 
Statistical  Mean 
Scale  Parameter 
Optimistic  Value 


Standard  Deviation* 
N/A 

Standard  Deviation1 
Threshold  Constant^ 
N/A 
N/A 

Shape  Parameter: 
Shape  Parameter1 
Most  Likely  Value 


1.  MUST  NOT  BE  ZERO 

2.  This  is  the  minimum  value  drawn  from  the  exponental  distribution. 

3.  Input  Module  use  only  (with  Form  20). 


4.  Implied  thresliold  constant  of  zero,  i.e.,  minimum  value  -  0. 

5.  Main  Module  use  only  (wi  :h  Form  12  and  13). 

6.  For  pessimistic  value  field  see  appropriate  Form  12  or  20.  CAUTION:  The  triangular 
distribution  acts  like  a  Beta  distribution.  Small  amounts  of  skewness  will  cause  the  mean  of  the 
triangular  distribution  to  move  away  from  the  most  likely  value  specified.  A  distribution  with 
Optimistic  (0)=1,  Most  Likely  (M)-2,  and  Pessimistic  (P)=5  will  have  a  mean  that  is  more  than  50% 
greater  than  the  most  likely  value.  The  mean  of  any  triangular  distribution  will  be  within  +  10% 
of  the  most  likely  value  if  the  following  conditions  are  true:  Where  these  conditions  cannot  be 
met,  use  of  the  exponential  or  some  other  distribution  is  recommended. 


NEGATIVE  SKEWNESS 


POSITIVE  SKEWNESS 


O  >  M  -  1.5  *  (P-M) 


P^M+  1.5  *  (M-O) 


Empirical.  Empirical  distributions  are  referred  to  by  placing  an  asterisk  and  the  assigned 
distribution  number  in  the  field  labeled  "MEAN."  Fields  labeled  DIST  and  VARIANCE  are  left  blank. 
The  distributions  themselves  are  defined  on  a  separate  input  form  (Input  Form  15  -  Distributions). 


D.  Initialization  Process 


The  Initialization  Process  consists  of  reading  the  input  data,  performing  the  necessary  data  edits, 
producing  a  user  reference  listing  of  the  data  as  produced,  and  preparing  a  compressed,  reformatted 
data  input  (Initialization)  for  the  Main  Module. 


All  the  input  data  records  (except  form  20s)  including  the  header  records  for  each  form  are  processed 
by  the  Input  Module.  The  finiil  record  in  the  data  must  contain  a  99  in  column  2  and  3  as  was  the  case 
of  the  specific  forms. 


Data  is  processed  and  printed  as  input  with  user  diagnostics  messages  both  interspersed  throughout  the 
listing  and/or  collectively  placed  at  specific  points  in  the  processing.  Often  the  user  is  warned  of  the 
same  data  error  or  inconsistency  in  more  than  one  place  in  the  listing,  ;>articularly  those  conditions 
causing  the  severest  problem  in  completing  the  Initialization  Process. 

Specific  information  required  on  each  of  the  forms  will  be  found  in  Chapter  VIII. 

NOTE:  It  is  the  inherent  responsibility  of  the  user  to  go  through  the  entire  Input  Module  output  and 
inspect  all  diagnostic  messages.  Problems  should  be  corrected,  assumptions  understood  and  accepted 
or  corrected,  and  all  warnings  heeded.  This  is  particularly  true  when  non-fatal,  but  still  serious 
conditions  in  the  data  exist,  and  an  Initialization  is  produced.  REMEMBER  -  CHECK,  DON'T  ASSUME. 

E.  Sortie/Activity  Generation  -  Scenario  Flying  Program 

The  Sortie/Activity  Generator  is  the  part  of  the  Input  Module  that  produces  the  mission,  sortie,  and 
activity  requirements  that  drive  the  Main  Module's  simulation.  This  is  normally  referred  to  as  the 
external  (Exogenous)  file  and  represents  the  scenario  flying  and  processing  program. 

All  the  input  data  Form  20  records  including  its  header  record  are  input  to  this  process.  The  final 
record  in  this  data  must  contain  a  99  in  column  2  and  3  as  was  the  case  with  Form  20.  This  Form  20 
mission  and  activity  information  is  provided  as  the  framework  from  which  the  total  external 
requirements  are  generated.  Basically,  the  following  general  information  is  needed: 

1.  The  total  number  of  days  of  mission/ activity  requirements  to  generate. 

2.  The  number  of  missions  to  be  flown  or  activities  to  be  processed  on  each  particular  day. 

3.  A  designated  take  off  time  for  each  mission  or  start  time  for  each  activity. 

4.  How  many  and  what  type  of  aircraft  are  required  by  each  particular  mission  and  activity  or 
what  non-aircraft  resources  are  required  for  a  particular  activity. 

5.  Identification  of  each  mission,  i.e.,  cross  country,  interdiction,  etc.,  or  activity,  i.e.,  TCTO. 

6.  How  long  each  mission's  sorties  will  last  (activities  hav-  no  sorties). 

7.  Each  mission's  or  activity's  priority  relative  to  other  missions  and  activities. 

The  Input  Module  takes  this  data,  edits  it,  produces  a  list  of  applicable  diagnostics,  and  generates  by 
time  of  day  a  tape  of  sequential  mission  and  activity  requirements  t>  be  read  and  acted  upon  by  the 
Main  Module.  A  listing  of  this  output  is  also  provided,  if  requested. 

F.  Output  Products 

The  three  specific  outputs  of  the  Input  Module  are  (1)  the  Exogenous  file  which  contains  the  flying 
programs,  (2)  the  main  module's  Initialization  file  whidi  contains  the  reformatted  input  data,  and  (3)  an 
output  listing  of  the  input  data  as  processed  with  applicable  diagnostics. 

Included  in  this  listing  will  be  the  following: 

1.  A  print-out  of  the  selected  run  options  (5PEC  card  information). 

2.  An  expanded  listing  of  the  processed  cards  beginning  at  the  top  of  a  new  page  for  the  first 
card  of  a  group  of  cards  with  the  same  form  numbers. 

3.  Embedded  diagnostics  or  warnings  usually  relating  to  the  input  data  immediately  prior  to  the 
message.  Appendix  B  lists  all  the  possible  messages  with  a  description  of  their  meanings  and  uses. 
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4.  Lists  of  diagnostics  or  warnings  at  the  end  of  each  group  of  forms  processed. 

5.  If  an  Initialization  is  produced,  a  set  of  dictionaries  and  a  listing  of  the  control  table  are 
printed.  These  will  be  discissed  below  in  detail  in  Paragraph  G. 

G.  Specific  Output  Reports  or  Sections 

1.  SPEC  Card  Information  See  Figure  9-14 

AJI  of  the  run  specifications  (SPEC  card)  options  either  selected  by  the  user  or  defaulted  are  listed 
under  this  title.  Included  are  any  pa'ameters  or  file  assignments  associated  with  the  option.  See 
Chapter  VI  for  details  of  ail  Input  module  SPEC  card  options. 

2.  Report  Specifications  -  See  Figure  9-15 

This  report  reflects  the  Form  10  input  data  processing  and  consists  of  a  mirror  image  reprinting  of  the 
input  records.  Applicable  diagnostic  messages  will  be  embedded  within  the  report. 

3.  Resource  Definitions  -  Se.n  Figure  9-16 

This  report  reflects  the  Form  13  input  data  processing  and  consists  of  an  expanded  reprinting  of  the 
input  records.  Column  headings  art-  duplicates  of  those  on  Form  13.  Applicable  diagnostic  messages 
will  be  embedded  within  the  report  Any  sequence  numbers  in  the  data  records  (Col  73-80)  will  print  to 
the  right  of  the  page. 

4.  Task  Resource  Requirements  -  See  Figure  9-17 

I  The  first  part  of  this  report  reflects  the  Form  12  input  data  processing  and  consists  of  an  expanded 
reprinting  of  the  input  records.  Column  headings  are  similar  to  those  on  Form  12.  Applicable 
diagnostic  messages  will  be  embedded  within  the  report.  Any  sequence  numbers  in  the  data  records 
(Col  73-80)  will  print  to  the  extreme  right  of  the  page. 

The  second  part  of  this  report  is  actually  diagnostic  message  140.  All  cases  of  circular  substitution  on 
any  Form  12  or  12A  are  listed.  The  list  includes  resources  that  can  substitute  for  another  resource 
named  on  the  same  form  and  reso>rces  that  are  not  on  the  form  but  can  substitute  for  more  than  one 
resource  named  on  the  same  form. 

5.  Task  Network  -  Input  Data  -  See  Figure  9-18 

This  report  reflects  the  Form  11  input  data  processing  and  consists  of  an  expanded  reprinting  of  the 
input  record.  However,  the  Selection  Mode  has  been  printed  between  the  Prior  Node,  indicated  by 
"NODE",  and  the  task  ID  columns  for  ease  of  reading  the  data.  Column  headings  are  the  same  as  those 
in  the  form  with  the  addition  of  the  first  column  '  INDEX". 

A  control  table,  which  is  primarily  a  coded  task  network,  is  used  by  the  Main  Module  instead  of  using 
node  names.  There  is  a  direct  one  to  one  mapping  of  the  row  indices  of  the  control  table  to  the  form 
11  input  records  where  record  1)1  is  in  row  1  of  the  table,  record  2  in  row  2,  etc.  The  printing  of  the 
"INDEX"  is  an  aid  to  the  user  when  using  the  control  table.  The  control  table  will  be  further  described 
later  in  this  section. 

Applicable  diagnostic  messages  will  be  embedded  within  this  repert.  Any  sequence  numbers  in  the  data 
records  (Col  73-80)  will  print  to  the  extreme  right  of  the  page. 

6.  Resource  Clock  Decrement?  -  See  Figure  9-19 

This  report  reflects  the  Form  14  input  data  processing  and  consists  of  an  expanded  reprinting  of  the 
input  record.  Column  headings  are  a  duplicate  of  those  on  form  14.  Applicable  diagnostic  messages 
will  be  embedded  within  the  report.  Any  secfjence  numbers  in  the  data  records  (Col  73-80)  will  print  to 
the  right  of  the  page. 


3— j 


This  report  reflects  the  Form  17  input  data  processing  and  consists  of  an  expanded  reprinting  of  the 
input  records.  Column  headings  differ  from  the  Form  17s  us  follows,  but  the  meanings  are 
synonymous; 

Form  17  Title  Report  Title 


Mission  I.D.  or  Activity  I.D. 


M5N/ACTY  I.D. 


Report  Column 


RPT  COL 


Network  Entry  Point  Node 


Network  Entry 


Pre- Sortie  External  Configuration 


Pre-Sortie  Ext  Conf 


Post-Sortie  External  Configuration 


Post-Sortie  Ext  Conf 


Aircraft  Assignment  Search  Pattern 


5earch  Pattern 


Aircraft  Name 


Aircraft  Name 


Applicable  diagnostic  messages  will  be  embedded  within  the  rep<  rt.  Any  setfience  numbers  in  the  data 
records  (Col  73-80)  will  print  to  the  right  of  the  page. 

10.  Aircraft  Assignment  Search  Patterns  -  S<  e  Figure  9-23 


3-7 


This  report  reflects  the  Form  15  input  data  processing  and  consists  of  an  expanded  reprinting  of  the 
input  records.  Column  headings  are  a  duplicate  of  those  on  Form  15  with  one  exception  -  the  Form  15 
Format  (Coi  1 1)  prints  along  with  the  TYPE  (Col  f)  under  the  same  report  heading  "TYPE".  Applicable 
diagnostic  messages  will  be  embedded  within  or  following  the  report.  Any  sequence  numbers  in  the 
data  records  (Col  73-80)  will  print  to  the  right  of  the  page. 


Subsequent  to  the  processing  of  the  data,  the  actual  distribution  it  listed  by  Distribution  No.,  the  left 
column  contains  all  the  probabilities  and  the  right  column  contains  all  the  values  (modified  by  the 
multiplier  if  present).  This  value  is  in  decimal  days. 


8.  Shift  Policies  -  See  Figure  9-21 


This  report  reflects  the  Form  16  input  data  processing  and  consists  of  an  expanded  reprinting  of  the 
input  records.  Column  headings  are  a  duplicate  of  those  on  form  14  with  the  exception  of  the  "Code" 
heading  which  is  missing.  However,  the  code  data  is  printed  at  the  extreme  left  of  the  report  in  its 
proper  location.  Continuation  numbers  (Col  6)  will  he  printed  with  the  code.  Applicable  diagnostic 
messages  will  be  embedded  within  the  report.  Any  sequence  numbers  in  the  data  records  (Col  73-80) 
will  print  to  the  right  of  the  page. 


9.  Mission  Entry  Points  -  Configurations  (Classes)  See  Figure  9-22 


This  report  reflects  the  Form  21  input  data  processing  and  consists  of  an  expanded  reprinting  of  the 
input  data  records.  Column  headings  are  a  duplicate  of  those  on  Form  21.  The  continuation  card 
character  (Col-11)  prints  with  the  Aircraft  Assignment  Search  Pattern  name  in  the  first  column. 
Applicable  diagnostic  messages  will  be  embedded  within  the  report.  Any  sequence  numbers  in  the  data 
records  (Col  73-80)  will  print  at  the  extreme  right  of  the  page. 


Empirical  Distributions  -  See  Figure  9-20 


I  11.  Internal  Equipment  Autnorizations/Trigger  Node  Changes  See  Figure  924 

This  report  reflects  the  Form  22  input  data  processing  and  consists  of  an  expanded  reprinting  of  the 
input  data  records.  Column  headings  are  similar  to  those  on  Form  22.  Applicable  diagnostic  messages 
will  be  embedded  within  the  report.  Any  sequence  numbers  in  the  data  records  (Col  73-80)  will  print  at 
the  extreme  right  of  the  page. 

|  12.  Internal  Equipment  Group  Definitions  -  Set  Figure  9-25 

This  report  reflects  the  Form  23  input  data  processing  and  consists  of  an  expanded  reprinting  of  the 
■  input  data  records.  Column  headings  are  a  duplicate  of  those  on  Form  23.  Applicable  diagnostic 
messages  will  be  embedded  within  the  report.  Any  sequence  numbers  in  the  data  records  (Col  73-80) 
will  print  at  the  extreme  rignt  of  the  page. 

13.  Form  20  Processing  -  See  Figure  9-26 

This  report  reflects  the  Form  20  input  data  processing  and  consists  of  three  sections. 

Section  1  will  always  print  and  consists  of  a  mirror  image  reprinting  of  the  entire  input  data  records. 
As  such,  columns  are  not  identified  by  any  headings.  Applicable  diagnostic  messages  will  be  embedded 
within  this  part  of  the  report. 

Section  2  prints  only  when  the  second  Form  20  data  record  containsan  "L"  in  Column  1  or  the  word 
"LIST"  in  Columns  1-4.  The  number  of  days  printed  will  be  that  which  was  requested,  i.e.,  the  number 
following  the  word  "list".  The  headings  and  data  printed  are  as  follows: 


Heading 

Data  Description 

Time 

Frag  (Request)  time  for  the  mission  or  activity 

Mission 

Mission  or  activity  name 

Aircraft  Type 

Name  of  air  era:  t  or  non-aircraft  resource  entering  network 

Sched 

Maximum  //  of  aircraft  or  non-aircraft  resources  requested.  99 
means  all  available  (on-hand) 

Min 

Minimum  number  aircraft  required  for  mission 

Spare 

Number  of  aircraft  requested  as  spares 

Priority 

Mission  or  activity  priority 

Take-off 

Scheduled  take-off  time  or  activity  request  time 

Lateness 

Tlie  interval  time  after  the  scheduled  take-off  time  prior  to  cancelling 
the  mission  -  in  days,  hours,  and  minutes  (d+h+m) 

Sortie  Length 

Actual  sortie  length  in  (d+h+m) 

Lead  Time 

The  interval  of  time  prior  to  scheduled  take-off  time  the  frag 
request  is  mace  (d+h+m) 

Section  3  always  prints  and  is  a  summary  bv  mission/ activity  type  of  the  flying  program  and  activity 
requirements  generated  for  the  period  specified  on  the  "List"  card,  Columns  5-7.  The  headings  and 
data  printed  are: 


) 
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Data  Description 

Either  Mission  or  Activity  Names 

Actual  number  of  missions  or  activities  generated 

Actual  number  of  sorties  generated.  Number  shown  here  for  activities 
should  always  equal  the  No.  of  Missions  column. 

Total  flying  hours  generated  by  mission  type.  Activities  must 
always  contain  a  zero  in  this  column. 

14.  Node  Usage  Report  -  See  Figure  9-28 


Headings 
MSName 
No.  Missions 
No.  Sorties 

Flying  Hours 


a.  Part  1  J 

This  report  is  a  valuable  aid  in  debugging  the  input  data  packages.  The  first  part  of  the  report  lists  all 
nodes  in  the  network  along  with  their  indexes  in  the  order  in  which  they  were  referenced.  The  index 
number  listed  is  the  one  at  the  first  use  of  the  node  on  the  Form  11s  as  a  prior  node.  Various  error 
conditions  are  indicated  under  the  CODES  heading.  A  count  of  all  reference  to  each  node  by  form 
number  and  data  field  are  tabularized.  The  headings  are  well  defined  at  the  beginning  of  the  report  so 
the  report  is  in  u  compressed  format. 

The  report  is  produced  automatically  by  the  Input  Module.  However,  because  of  its  volume,  the  first 
part  of  the  report  can  be  shortened  by  setting  INFO  less  than  3  on  the  Input  Module  SPEC  card.  This 
will  cause  only  the  nodes  with  error  codes  to  print.  The  various  error  conditions  include: 

Apparent  Static  Loop  (L)  -  From  the  node  referenced  the  loop  test  indicates  that  this  same  node  can  be 
reentered,  i.e.,  a  loop.  This  is  only  a  warning  message  since  this  could  be  a  valid  condition  if  the  user 
has  some  means  (A,  H,  or  F  selection  node,  etc.)  within  the  loop  to  stop  the  looping. 

Call  Section  Must  Not  Reach  a  Sortie  (X)  -  A  sortie  branch  has  been  found  in  a  network  section  that 
was  called  by  the  node  referenced.  Ensire  that  all  sortie  branches  are  in  the  main  line  network,  not  a 
called  section.  This  is  a  fatal  error. 

Conditional  Sortie  (C)  -  The  node  referenced  is  the  entry  node  of  a  network  that  contains  a  sortie  task 
(sel  mode  S)  that  cannot  be  reached  from  the  entry  node  100%  of  the  time.  Verify  that  the  network 
has  no  E  branches  prior  to  the  sortie  that  do  not  sum  to  100%  or  any  A  brandies  prior  to  the  sortie. 
This  is  a  fatal  error. 

Parallel  Sorties  (P)  -  The  node  referenced  occurs  either  at  the  entry  point  or  at  some  node  between  the 
entry  point  and  the  part  of  the  network  that  will  be  able  to  reach  parallel  sorties.  This  a  fatal  error  so 
the  network  must  be  corrected. 

Reconfiguration  Entry  Must  Not  Reach  a  Sortie  (R)  -  The  node  referenced  is  either  an  external  or  an 
internal  reconfiguration  entry  node  (specified  on  Form  22)  that  can  reach  a  sortie  task.  This  is  illegal 
so  ensure  that  no  reconfiguration  node  has  a  sortie  branch  in  its  network. 

Sequential  Sorties  (S)  -  The  node  referenced  is  the  first  sortie  in  a  network  path  which  includes  more 
than  one  sortie.  This  error  message  will  appear  even  if  one  of  the  sorties  occurs  illegally  in  a  call 
section.  Verify  that  the  network  has  no  double  sortie  branch  in  sequence  (even  with  intermediary 
branches  with  other  selection  modes). 

Undefined  node  (»)  -  This  is  a  node  that  has  references  in  Columns  2  thru  5  but  has  none  in  Column  1, 
i.e.,  it  never  appeared  on  a  Form  11  as  a  prior  node.  This  is  a  fatal  error  because  it  means  there  are 
real  voids  in  the  network  which  will  result  in  an  abort  condition  in  the  Main  Module  processing. 
Possible  corrective  actions  indude:  (1)  Rename  the  "next  node"  listed  to  match  an  applicable  "prior 
node"  to  which  it  is  to  be  linked;  (2)  Rename  an  applicable  "prior  node"  to  match  the  listed  undefined 
"next  node";  (3)  Remove  the  "next  node"  name  listed  as  the  undefined  node  if  the  prior  task  is  the  last 
task  in  that  branch  of  the  network  (no  subsequent  tasks  link  to  the  undefined  node). 
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NOTE:  When  renaming  nodes,  avoid  duplication  of  node  names  that  will  cause  improper  linking  to 
other  networks. 


Unused  Node  (»)  or  Unreachable  Node  (U)  -  This  is  a  node  that  has  references  only  in  Column  I,  i.e., 
defined  as  a  prior  node  on  a  Form  11  but  never  referenced  elsewhere.  This  is  only  a  warning  message 
s  nee  no  network  voids  exist;  only  extra  unnecessary  data  is  present  (and  may  be  the  user's  desire). 

b.  Part  2 


The  second  part  of  the  Node  Usage  Report  lists  all  nodes  with  parallel  branches.  The  index  and  the 
selection  mode  of  all  occurrences  of  the  source  node  are  listed  together.  This  report  replaces  the 
message  62s  which  used  to  appear  throughout  the  Task  Network  Report  (Form  11s)  wherever  the  same 
prio-  node  appeared  more  than  once. 

1 5.  Summary  Diagnostics  -  See  Figure  9-27 


This  section  of  the  Input  Module  run  between  the  Node  Usage  Report  and  Input  Data  Summary  is  not 
actually  a  report  but  a  collection  of  summary  diagnostic  messages  indicating  problems  or  lack  of 
problems  in  the  data  input.  Messages  that  will  be  found  here  are,  but  not  limited  to,  the  following 
message  numbers;  24,  36,  11,  79,  80,  96,  97,  117,  31,  etc.  When  error  conditions  exist,  additional 
messages  will  be  found  at  this  output  location. 


16.  Input  Data  Summary  -  See  Figure  9-29 

This  section/report  contains  a  summary  of  the  size 
summary  are  as  follows: 

Information  » 

Resources 

Task  Names 

Node  Names 

Control  Table  Entries 
Failure  Clocks 

Mission  Entry  Points  (IETB) 

Resources  Entering  Network  (NACO) 


of  the  input  data.  Sources  of  the  values  in  this 


Source 

No.  of  Resources  Defined  on 
Form  13. 

No.  of  Tasks  Defined  on  Form 
12. 

No.  of  Nodes  Defined  on  Form 
11. 

No.  of  Form  11  data  records. 

No.  of  Clocks  Defined  on  Form 
13. 

No.  of  Different  Entry  Nodes 
u;ed  on  Form  17. 

No.  of  A/C  defined,  +  Resources 
marked  in  Col  1 1  on  Form  1 3, 

+  1. 


Total  //  of  Configurations  Defined  (All  A/C)  (NCRS)  Total  //  of  different  configurations 

defined  on  the  Form  17s. 


Search  Patterns  (NSRPT) 


No.  of  Configuration  Management 
List  names  defined  on  Form 
21. 


Next  Higher  Failures  (NNHF) 


Task  Resource  Requirements  (TRR) 


Unique  Groups  of  Clock  Decrements  (NOCL) 


Unique  pieces  of  Int.  Equip.  (EQUIP) 


Indicator  of  F  tasks  stringing. 

This  no.  divided  by  no.  clocks 
is  the  average  depth  of  the  F 
string. 

No.  of  different  (TRR)  entries 
on  Form  12,  i.e.,  cols  37-63. 
Duplicates  are  removed. 

No.  of  different  groups  of  clocks 
decremented  by  constant  values 
on  Form  14. 

No.  of  different  int.  equip,  defined 
on  Form  22. 


Internal  Equip.  Groups  (ILIST) 
Triggering  Events  (NTEVT.DV) 
Operations  Headings  on  Form  10 
Aircraft  Headings  on  Form  10 
Personnel  Headings  on  Form  10 


No.  of  Int  Equip  Groups  defined 
on  Form  23. 

No.  of  trigger  nodes  defined 
on  Form  22  is. 

No.  of  entries  on  Form  10,  subtype 
03,  plus  1. 

No.  of  entries  on  Form  10,  subtype 
05,  plus  1. 

No.  of  entries  on  Form  10,  subtype 
07,  plus  1. 


Part  Headings  on  Form  10  No.  of  entries  on  Form  10,  subtype 

09,  plus  1. 

AGE  Headings  on  Form  10  No.  of  entries  on  Form  10,  subtype 

1 1,  plus  1. 

•Footnote:  Information  in  parenthesis  is  programmer  oriented. 

This  summary  is  an  indicator  of  not  only  the  size  of  the  input  data,  but  also  its  general  overall 
structure.  Dy  analyzing  the  relationship  of  the  values,  for  example,  the  ratio  between  the  "Next  high 
failures"  and  the  "Failure  Clocks"  the  average  depth  of  F  task  stringing  can  be  determined.  A  large 
ratio  indicates  clocks  are  being  used  at  a  lower  or  subsystem  level.  Other  similar  observations  can  be 
made. 


By  using  these  numbers  and  other  information  from  the  input  data  as  input  to  the  Core  Estimator  (see 
Appendix  B),  a  user  can  approximate  the  initial  Main  Module  core  requirements. 


17.  Dictionaries 


The  remainder  of  the  Input  Module  reports  are  termed  "Dictionaries."  These  are  ti>e  user's  primary 
interface  with  the  Main  Module.  The  dictionaries  are  required  since  the  names  assigned  by  the  user  to 
tasks,  resources,  missions,  etc.,  are  primarily  for  the  user's  benefit  and  are  not  carried  into  the  Main 
Module.  This  is  due  to  the  excessive  amount  of  memory  required  to  store  them.  They  are,  in  fact, 
used  by  the  Main  Module  but  only  in  terms  of  a  number  within  a  sequenced  list  of  names— hence,  the 
dictionaries.  These  are  very  useful  to  the  analyst  in  the  detailed  evaluation  of  the  Main  Module 
simulation  runs. 
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All  the  dictionaries  will  print  only  when  the  Input  Module  data  is  dean  of  all  fatal  error  messages, 
therefore,  if  they  are  printed,  an  Initialization  is  to  be  produced.  A  description  of  all  dictionaries 
follows. 


IS.  Resource  -  Dictionary  -  See  Figure  9-30 

This  dictionary  titled  "Resources"  prints  after  the  Input  Data  Summary.  It  not  only  contains  the 
assigned  numbers  of  the  resources,  as  referenced  in  the  Main  Module,  hut  includes  additional  isago 
infotrr  ation.  The  maximum  authorizations  (MXAUTH)  established  in  tha  input  data  (on  Form  13  or 
Form  16)  is  specified  here  along  with  the  maximum  single  usage  (MXUSE)  of  that  resource  on  a  task 
(Form  12).  Where  the  MXUSE  exceeds  the  MXAUTH,  a  Flag  U)  is  given.  Users  running  a  main 
simulation  run  without  correcting  this  situation  can  expect  the  run  to  bottleneck  on  the  resources  so 
i  flagged.  AUTH  and  SAUTH  change  cards  in  the  Main  Module  run  will  correct  this  situation.  The 
'  order  of  assignment  of  the  resource  ID  //' s  is  normally  the  order  the  resources  appear  n  on  ihe  Form 
•  I3's.  Hcwever,  they  are  in  the  order  of  appearance  on  the  Form  1 2’s  if  the  12’s  are  entered  before  the 
;  1  3’S. 

The  exact  definitions  of  the  columns  following  the  resource  name  are: 

MXAUTH  Authorized  quantity  established  on  Form  13,  Columns  24-27,  or  forresources 
on  a  shift,  the  maximum  shift  authorization  on  Form  16,  Columns  14-69. 

MXUSE  The  maximum  task  resource  requirement  quantity  specified  on  Form  12 

or  12A  in  Columns  44-45,  53-54,  or  62-63. 

FLAG  Will  print  out  as  a"+"  sign  if  the  MXUSE  is  greater  than  MXAUTH. 

19.  Failure  Clocks  -  Dictionary  -  See  Figure  9-31 

This  dictionary  lists  the  failure  dock  names  defined  on  Form  13  with  the  assigned  reference  number 
that  is  used  by  the  Main  Module. 

20.  Tasks  -  Dictionary  -  See  Figure  9-32 

This  dictionary  lists  the  tasks  defined  on  Form  12  with  the  assigned  reference  number  that  is  used  by 
the  Main  Module. 

21.  Task  Resource  Requirements  -  Duplicates  are  Merged  -  See  Figure  9-33A 

This  data  is  primarily  a  dictionary  (without  assigned  numbers)  of  the  Task  Resource  Requirements 
(TRR)  table.  Duplicate  TRR  requirements  (Col  30-35  and  37-63  on  Form  12)  have  been  eliminated 
from  this  table  resulting  in  a  substantial  savings  of  memory  in  the  Main  Module's  simulation  run.  The 
number  of  Duplicate  TRR  requirements  is  indicated  by  the  "Usage  Count."  The  table  is  structured  as 
sets  of  3  entries  across  the  page,  a  set  for  each  resource  required.  An  interpretation  of  each  entry  is 
as  follows: 

Resouce  Name  of  Resource 

QTY  (I)  Positive  number  is  quantity  from  Col  44-45,  53-54,  or  62- 

63. 

(2)  Negative  number  is  quantity  from  Col  44-45,  53-54,  or  62- 

63  as  before,  but  has  been  set  negative  to  indicate  a  C  for  "consume" 
has  appeared  in  the  assodated  Col  43,  52,  or  61. 

(3)  If  QTY  =  99999,  there  was  a  *  in  Col  29  and  the  resource 
field  is  from  Col  30-35. 

Sub  Flag  If  an  X  appears,  it  means  an  X  was  placed  in  the  V"  .'ield  (Col 

43,  52,  or  61)  to  activate  generalized  substitution. 

22.  Resource  Combination  Sets  -  See  Figure  9-33B 
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This  dictionary  is  a  further  breakdown  of  the  Task  Resource  Requirements  described  above,  but  it 
includes  only  those  groups  of  resources  described  on  a  Form  12A  with  a  specific  Resource  Combination 
Set  rame  (Cols  30-35). 

23.  External  Configurations  (Classes)  -  See  Figure  9-34 

This  dictionary  lists,  by  aircraft  type,  the  individual  external  configurations  (classes)  and  the  assigned 
reference  index  number  that  is  used  by  the  Main  Module.  Also  indicated  is  the  frequency  that  each 
class  is  searched  by  the  Aircraft  Assignment  Search  Patterns.  Message  53  always  prints  as  a  warning. 

24.  Aircraft  Assignment  Search  Patterns  -  See  Figure  9-35 


This  dictionary  lists  the  following: 


Name 

Aircraft 

No.  of  Refs 

No.  of  Classes 
Searched 


Description 

Assigned  Main  Module  reference  number. 

Aircraft  Assignment  Search  Pattern  Name. 

Particular  aircraft  using  this  search  pattern. 

No.  of  Form  17  missions  or  activities  using  the  search  patterns. 
Self-explanatory  (i.e.,  depth  of  search) 


25.  Internal  Equipment  By  Aircraft  -  See  Figure  9-36 

This  dictionary  lists  by  aircraft  type,  the  internal  equipment  name  defined  on  Form  22,  its  assigned 
Main  Module  reference  index,  and  the  frequency  of  its  reference  on  Form  23. 

26.  Interned  Equipment  Groups  -  See  Figure  9-37 


This  dictionary  lists  the  following: 


Name 


Aircraft 

No.  of  Refs 

No.  of  Equipment 
Referenced 


Description 

Assigned  Main  Module  reference  number 

Internal  equipment  names  from  Form  23 

Particular  aircraft  type  using  this  group 

Number  of  Form  21  references  to  this  fp'oup 

Number  of  internal  equipment  names  referenced  by  this  group 
on  Form  23. 


27.  Control  Table  -  See  Figure  9-38 

This  dictionary  is  the  most  important  for  the  user  to  understand.  It  is  a  convenient  way  to  pass  the 
network  to  the  Main  Module's  simulation  process  and  when  thoroughly  understood,  is  an  exceptionally 
good  debugging  tool.  It  is  merely  a  tabularization  of  the  Form  11  network.  In  fact,  Row  inde/  ftl  is 
the  first  Form  11  record;  Row  2,  the  second  Form  11  record,  ...  etc.  Sequence  numbers  indices  have 
been  added  in  front  of  the  Form  11  Network  processing  records  for  ease  of  reference  back  and  forth 
between  the  input  network  data  and  this  control  table.  The  information  provided  is  as  follows: 


IV.  MAIN  MODULE 


A.  General  Description 

1.  Overview 

The  main  module  of  the  LCOM  II  Simulation  Software  is  designed  to  simulate  a  broad  range  of  aircraft 
operations,  scheduling,  maintenance,  and  supply  functions  at  an  Air  Force  base.  In  accordance  with 
the  LCOM  II  design  objectives,  the  logical  ordering  of  actions  within  the  simulation  may  be  adapted  to 
many  problem  situations  and  therefore  must  be  specified  by  the  user  for  his  specific  application.  The 
user  is  free  to  define  both  the  resources  of  interest  and  the  manner  of  their  intended  utilization,  while 
the  software  provides  the  necessary  controls  and  structire  to  simulate  and  maintain  a  record  of  their 
action  and  interaction. 

Although  LCOM  II  Simulation  Software  specifically  addresses  an  AF  base,  the  techniques  used  permit 
the  potential  application  of  the  software  to  the  depot  structire  both  in  terms  of  its  relationship  to  the 
base  or  specifically  the  depot  itself. 

2.  Simulation  Process 

Using  the  Initialization  and  Exogenous  file  produced  by  the  Input  Module,  the  simulation  process  is 
undertaken  for  some  desired  period  of  time.  The  maintenance  requirements  are  generated  during  the 
simulation  by  combining  the  simulated  flying  of  aircraft  (Exogenous)  and  the  inputted  failure  rates  as 
guided  by  the  input  maintenance  data  (Initialization),  the  resources  are  demanded  and  utilized,  aircraft 
are  serviced,  inspected  if  necessary,  and  returned  to  serviceable  condition  to  fly  again.  During  the 
simulation,  reports  are  produced  showing  the  operational  effectiveness,  spares  requirements,  stock 
level  performance,  and  a  variety  of  resoirce  utilization  and  performance  data.  Since  not  all  reports 
and  their  associated  trend  analysis  can  be  accomplished  during  the  simulation  process  transaction, 
typed  data  is  collected  and  stored  on  a  file  for  subsequent  processing  by  a  set  of  post  processor 
programs.  Reports  from  these  post  processors  aid  in  the  total  simulation  analysis. 

3.  Data  Requirements 

There  are  three  distinct  functional  areas  at  an  Air  Force  base;  that  of  operations,  maintenance,  and 
supply.  These  areas,  without  fully  considering  the  effects  of  the  others,  will  always  leave  something  to 
be  desired. 

No  existing  simulation  model  has  been  able  to  completely  address  this  overlap  in-depth  within  a  single 
model.  There  are  many  models  which  address  a  specific  area  in  depth  but  sacrifice  the  total  effects  of 
the  other  areas  by  abstracting  them  to  some  degree.  LCOM  II  Simulation  Software  has  been  designed 
to  adequately  address  this  overlap  by  permitting  the  information  and  logic  of  each  specific  area  to  be 
user  described  in  terms  of  some  data  base.  This  data  represents  the  environment  at  the  specific  base, 
wing  or  squadron,  whichever  is  being  simulated. 

The  explicit  purpose  of  the  simulation  software  is  to  provide  a  capability  to  represent  the  demand 
processes  and  reflect  the  interaction  of  support  resources  availability,  i.e.,  aircraft,  men,  parts,  and 
equipment,  both  on  flight  line  and  in  shops.  In  order  to  accomplish  this,  the  software  requires  user 
provided  logic  in  the  form  of  a  network  of  information.  This  "task  network  representation"  is  the  key 
LCOM  II  feature  which  permits  the  user  to  describe  the  maintenance  environment  to  whatever  depth 
desired  in  terms  of  a  sequence  of  tasks  required  on  the  aircraft  or  any  of  its  recoverable  parts. 

The  LCOM  II  Simulation  Software  utilizes  three  basic  data  soirees: 

a.  Operations  data,  which  includes  the  number  of  missions,  mission  type  ,time  of  take-off, 
sortie  duration,  number  of  aircraft  required,  and  other  related  mission  data.  Included  in  this  data  are 
the  activities,  user  defined  external  requirements  for  either  aircraft  or  non-aircraft  resources  which 
are  to  be  processed  in  such  a  manner  that  does  not  lead  to  or  involve  a  sortie  task. 


b.  Maintenance  data,  which  is  primarily  AFM  66-1  data,  in  the  form  of  a  maintenance 
network,  the  structure  of  which  will  be  described  later.  This  data  includes  necessary  scheduled 
maintenance  actions  required  on  both  aircraft  and  non-aircraft  resources. 

c.  Supply  data,  which  includes  the  supply,  demand,  and  resupply  processes  at  the  various 
levels  of  part  indentures,  i.e.,  assembly,  sub-assembly,  sub-sub-assembly,  module,  etc.,  according  to 
the  user  definition.  Generally  Work  Unit  Code  references  are  used. 

4.  Information  Structure  -  See  Figure  4-1 

The  main  module  expects  the  user  environment  to  be  described  in  three  basic  network  segments;  pre¬ 
sortie,  sortie,  and  pcst-sortie.  Additional  optional  segments  are  the  external  and  interna! 
reconfiguration  networks.  These  segments  will  be  described  in-depth  in  the  feature  descriptions 
portion  of  this  chapter.  The  relationship  of  these  segments  are  reflected  in  Figure  4-1.  The  segment 
called  sortie  is  in  reality  only  one  task,  the  sortie  task.  However,  frequently  in  parallel  to  this  task  are 
the  clock  decrement  ta.ks  (to  be  described  later). 

The  size  and  complexity  of  the  rest  of  these  segments  are  entirely  controlled  by  the  user.  The 
following  discussion  indicates  the  depth  to  which  these  network  segments  can  and  often  are  defined  by 
the  user. 

During  the  course  of  the  simulation,  various  types  of  missions  and  activities  are  scheduled  based  upon 
operations  data  provided  by  the  user.  For  each  mission  requirement,  the  main  module  controls  the 
processing  of  each  aircraft  thru  the  pre-sortie  networks  towards  the  completion  of  the  mission  (the 
sortiefe))  then  through  any  user  defined  maintenance  which  may  result  from  the  mission.  This  is 
illustrated  in  Figure  4-1.  As  in  real  life,  the  main  module  attempts  to  complete  all  missions,  out  some 
cannot  be  completed  as  scheduled. 

After  the  mission  is  completed,  the  aircraft  will  process  thru  the  user  defined  post-sortie  tasks.  These 
tasks  would  normally  include  debriefing  and  troubleshooting  tasks  in  which  aircraft  system  failures  are 
detected  and  their  correction  begun.  This  phase  of  the  simulation  would  be  where  the  user  specifies 
the  demands  for  spares  from  supply,  and  simultaneously  generates  reparable  assemblies  for 
maintenance  in  the  base  repair  shops,  or  in  the  case  of  NRTS  (Not  Reparable  This  Station)  items,  the 
depot-level  repair  facilities. 

Maintenance  at  this  point  could  follow  two  distinct  paths:  one  for  the  aircraft  itself  (flightline 
maintenance)  and  one  for  the  reparable  assemblies  (shop  maintenance). 

Flightline  maintenance  normally  consists  of  those  tasks  required  to  troubleshoot  and  remedy  failures 
either  on  the  aircraft  or  by  replacement  of  faulty  items  with  serviceable  spares.  After  all  aircraft 
maintenance  is  completed,  the  aircraft  is  returned  to  a  serviceable  pool,  or  if  the  maintenance  was 
required  during  pre-sortie  processing  leading  to  a  mission  which  is  still  valid  (scheduled),  the  aircraft 
continues  processing  its  pre-sortie  tasks. 

Shop  maintenance  tasks  are  those  base  or  depot  tasks  required  to  troubleshoot  the  reparable  assembly 
and  remedy  the  failure  by  repair  and/or  replacement  of  one  or  more  of  its  first  indenture  assemblies, 
followed  by  some  functional  test.  Following  the  replacement,  a  second  indenture  reparable  may  be 
generated  for  further  base  or  depot  maintenance.  This  method  of  sub-indenture  failure  generation  can 
be  repeated  down  to  anv  level  and  is  dependent  only  upon  the  data  availability  and  computer  capacity. 
For  each  indenture,  maintenance  is  accomplished  in  the  same  manner  as  described  above.  Individual 
reparable  items  follow  either  their  own  maintenance  tasks  as  described  by  the  input,  or  a  general 
abstracted  set  of  maintenance  tasks,  as  might  be  the  case  at  the  lowest  indentures  stuidied. 

Whether  to  repair  an  item  at  base  or  depot  is  a  selec.ion  based  upon  the  input  NRTS  (to  depot) 
percentage  for  that  item.  In  each  case,  the  reparable  follows  a  specific  set  of  tasks.  cor  the  depot, 
this  set  of  tasks  can  be  described  as  a  single  task  representing  the  depot  order  and  shipping  time.  Upon 
completion  of  the  designated  tasks  at  either  base  or  depot,  the  unit  is  returned  to  base  supply  as  a 
serviceable  item  and  appropriate  stock  levels  are  incremented. 
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FIGURE  4-1  OVERALL  BASIC  MODEL  NETWORK  AND  TIMING  LOGIC 
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Statistical  data  generated  by  the  simulation  is  collected  and  summarized  during  the  entire  operati  an  of 
the  model  and  at  specific  times  designated  by  the  user,  is  produced  in  output  formats  for  his  analysis. 
Section  C  of  this  chapter  describes  the  output  portion  of  the  model,  the  specific  reports  available,  and 
the  users  options  in  obtaining  these  reports. 

5.  Summary 

The  main  module  performs  six  distinct  functions;  (1)  activates  and  controls  all  mission  processing,  (2) 
activates  all  activity  processing,  (3)  inserts  appropriate  reconfigiration  prior  to  functions  1  and  2,  (4) 
controls  resource  processing  through  user  defined  networks,  (5)  collects  base  statistics  and  prepares 
repons,  and  (6)  taps  out  requested  data  to  be  further  processed  by  the  post  processors. 

B.  Feature  Descriptions 

LCOM  H  is  composed  of  many  individual  features.  These  features  interrelate  with  each  other  in  a 
variety  of  ways,  each  way  dictated  by  the  simulation  circumstances  at  the  particular  time  the 
interface  takes  place.  It  will  not  be  necessary  to  describe  all  of  the  possible  interfaces  between  the 
features,  but  the  features  themselves  and  any  major  interfaces  will  be  described. 

LOOM  II  features  can  be  categorized  as;  (1)  those  that  operate  without  user  controls,  (2)  those  the 
user  can  partially  control,  and  (3)  those  entirely  user  controlled.  No  attempt  will  be  made  to  describe 
all  those  in  category  1  except  when  it  is  important  to  know  what  they  do  or  how  they  work  as  a  basis 
for  understanding  one  of  the  user  controlled  features.  All  user  controlled  features  are  described. 

Many  of  the  user  controlled  features  are  "selectable,"  in  that,  if  a  user  does  not  specifically  request 
their  'jse  or  define  the  data  that  controls  them,  the  main  module  will  not  use  them,  for  example,  the 
|  shift  mechanism.  In  general  old  LCOM  II  data  cases  (for  Version  1.2)  will  run  against  this  documented 
I  Version  3.5  with  only  a  replacement  of  Form  21  data  for  Form  19  data  and  Version  2.0  data  is  upward 
•  compatible  with  this  version  except  that  general  substitutions  must  be  activated  by  resource  on  the 
i  Form  12's.  Regardless  of  past  user  knowledge  of  the  features,  it  is  suggested  that  the  descriptions  that 
follow  be  reviewed  in  detail. 

1.  User  Controls 

There  are  three  basic  user  controls  over  the  main  module.  They  are:  the  SPEC  card,  CHANGE 
CARDS,  and  Control  Switches  called  SWICH(N).  They  are  briefly  described  as  follows: 

a.  SPEC  CARD  -  REQUIRED 

Each  SIMSCRIPT  II  program  in  the  LCOM  II  system  utilizes  the  same  overall  design  for  input  of  user 
options.  A  single  card  or  record  called  the  SPEC  (specification)  card  is  utilized  for  this  pirpose  and 
must  be  included  as  the  first  data  record  read.  Basic  user  options,  such  as,  file  assignments,  can  be 
established  through  use  of  this  SPEC  card.  The  input  of  each  option  is  free  form,  that  is,  the  option 
,  can  be  placed  anywhere  on  the  card,  in  any  order,  but  at  (east  one  blank  character  must  separate  any 
|  two  options.  Only  72  characters  of  the  SPEC  record  are  used.  No  additional  SPEC  card  is  permitted 
;  for  the  main  module.  See  Chapter  VI  for  details  on  the  main  module  SPEC  card. 

b.  CHANGE  CARDS  -  All  but  one,  the  STOP  card,  are  optioned. 

Once  the  Input  Module  produces  an  initialization  file  for  the  Main  Module  to  process,  the  user  may  find 
it  necessary  to  make  certain  run  specifications  or  make  certain  small  variable  changes  prior  to  the 
simulation  run.  It  is  possible,  depending  on  the  variable,  to  make  these  changes  or  specifications 
during  the  Main  Module  processing  and  consequently  avoid  additional  input  processing.  CHANGE 
CARDS  have  been  defined  to  permit  this  action.  The  CHANGE  CARDS  are  included  as  a  part  of  the 
run  deck  on  the  CHANGE  file  designated  on  the  Main  Module  SPEC  Card.  See  Chapter  VII  for  details 
on  the  CHANGE  Cards. 
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c.  SWICH  CONTROLS  -  Optional 


An  important  CHANGE  card  is  the  one  called  SWICH.  It  controls  15  different  switches  in  the  main 
module.  Each  of  these  switches  has  a  specific  user  function  to  perform.  In  addition,  this  feature  also 
permits  a  set  of  callable  diagnostics  to  remain  within  the  debug  version  of  the  main  module  to  assist  in  j 
any  program  debug  and  in  futire  program  development.  Only  switches  4  and  5  are  set  on  automatically  ! 
by  the  input  module.  All  others  are  off  at  the  start  of  the  run.  Normally,  the  switches  are  bimodal 
where  "0"  is  off  and  "1"  is  on.  Some  switches  permit  additional  values  greater  than  1.  See  Chapter  VII  j 
and  Table  7-1  for  details. 

2.  Processing  Requirements  -  Missions  and  Activities 

The  Main  Module  is  designed  to  respond  primarily  to  a  scheduled  workload  of  aircraft  and  non-aircraft 
processing  requirements  as  generated  by  the  input  data.  This  response  is  done  in  the  following  manner: 

a.  Missions  and  Sorties 

Missions  are  those  aircraft  requirements  that  process  portions  of  a  network  of  tasks  that  lead  to  and 
include  a  sortie  task.  Aircraft  sorties  have  a  direct  and  unseverable  relationship  with  missions. 
Missions  are  scheduled  and  consist  of  one  or  more  sorties,  each  representing  one  aircraft.  Different 
types  of  aircraft  may  be  related  to  different  missions  as  defined  on  Input  Form  17,  but  must  be 
requested  on  Form  20  by  take-off  time.  Specifics  about  defining  and  requesting  missions  are  described 
in  Chapter  VIII.  Figure  4-1  is  applicable  to  much  of  this  section  so  further  references  to  it  have  been 
omitted. 

The  mission  is  placed  on  the  schedule  (exogenous  file  by  the  input  module)  at  take-off  time  minus  the 
lead  time  specified  for  the  processing  of  pre-sortie  tasks.  The  number  of  sorties  required  for  the 
mission  is  determined  and  the  mission  ownership  of  the  member  sorties  is  established.  The  number  of 
sorties  scheduled  is  equal  to  the  maximum  aircraft  identified  on  input  form  20.  An  equal  number  of 
aircraft  are  requested  for  the  mission  plus  any  spares  designated. 

The  pre-sortie  set  of  tasks  is  started  for  each  sortie  by  first  obtaining  a  properly  configured  aircraft 
from  the  on-hand  balance  of  those  available.  If  other  than  the  requested  configuration  is  obtained,  the 
proper  section  of  reconfiguration  tasks  is  added  in  front  of  and  processed  prior  to  the  pre-sortie  tasks. 

A  more  detailed  description  of  the  aircraft  configuration  feature  is  described  within  this  section  under 
the  title  of  Configuration  Management.  If  an  aircraft  cannot  be  found,  the  demand  is  backordered 
until  satisfied.  Once  satisfied,  the  processing  of  the  pre-sortie  task  and  any  applicable  reconfigiration 
tasks  are  begun. 

As  each  aircraft  assigned  to  the  mission  completes  its  pre-sortie  tasks,  the  aircraft  is  flagged  ready  to 
go  on  the  mission.  When  the  scheduled  take  off  time  for  the  mission  arrives,  the  number  of  ready 
aircraft  are  checked  and  if  enough  are  ready,  the  mission  goes,  i.e.,  each  aircraft  (up  to  the  maximum 
requested)  begins  its  sortie  task.,  spares  are  released  as  serviceable  aircraft  and/or  any  not  ready 
aircraft  are  flagged  as  late  for  the  mission  but  continue  to  process  towards  the  sortie  task  for 
subsequent  release  as  a  serviceable  aircraft.  If  insufficient  aircraft  are  available,  the  mission  is 
delayed  until:  (1)  sufficient  aircraft  become  ready  or  (2)  the  time  to  cancel  the  mission  arrives, 
whichever  occurs  first. 

If  the  time  to  cancel  the  mission  occirs  first,  a  final  check  is  made  to  see  if  there  are  sufficient  l 
aircraft  to  "replace"  up  to  the  minimum  those  currently  assigned  but  not  ready  to  fly  in  order  to  i 
accomplish  the  mission.  Replacement  aircraft  are  those  aircraft  in  the  correct  configuration  and  , 
readv  to  fly  condition.  If  there  are  sufficient  replacement  aircraft  they  are  assigned  (plugged  into  the  , 
mis  ion)  and  the  mission  will  be  accomplished.  Otherwise;  (1)  the  entire  mission  is  scrubbed,  (2)  all  ( 
ready  aircraft  are  released  as  serviceable  aircraft,  (3)  any  pre-sortie  processing  aircraft  are  flagged  as  ( 
late  for  their  mission  but  continue  processing  towards  the  sortie  task  for  subsequent  release  as  a  ( 
serviceable  aircraft,  and  (4)  any  outstanding  requests  for  aircraft  for  the  mission  are  cancelled.  i 

Once  the  sortie  task  is  completed,  the  aircraft  begins  its  set  of  post-sortie  tasks.  When  these  are 
complete,  the  aircraft  is  released  to  the  simulation  as  a  serviceable  aircraft  for  subsequent 
reassignment. 


b.  Activities 


Activities  are  those  processing  requirements  that  process  portions  of  a  network  of  tasks.  However, 
these  networks  must  not  contain  a  sortie  task.  They  can  be  processed  by  either  an  aircraft  or  non-’ 
ai' craft  resource.  Normally,  this  type  of  processing  will  be  actions  such  as;  snow  removal  from 
runways,  special  aircraft  ground  processing,  test  equipment  modification,  time  compliance  technical 
orders  (TCTOs),  etc. 

Activities  are  defined  on  Form  17  and  must  be  requested  on  Form  20  by  requested  time  of  activity 
start-up.  Specifics  about  defining  and  requesting  activities  is  described  in  Chapter  VIII,  and  in  the 
Chapter  IV  feature  description  Time  Controlled  Activity  Processing. 


3.  Network  Description 
a.  Terms 

The  support  environment  for  any  LCOM  II  simulation  is  described  for  the  model  in  terms  of  a  network 
of  tasks.  A  task  is  defined  as  a  requirement  for  resources,  men,  parts,  equipment,  and  time;  and  has  a 
defined  relationship  with  other  tasks  in  terms  of  either  successor,  series,  or  parallel  tasks.  Figure  4-2 
contains  the  basic  network  terms  and  their  definitions.  This  network  is  defined  on  Form  1 1.  Chapter 
VIII  describes  the  specifics  for  defining  the  networks. 
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Terms 

NETWORK 

NODE 

BRANCH 

TASK 

SELECTION  MODE 


SELECTION  PARAMETER 

V _ 


Definition 

-  A  logical  flow  of  actions  represented  by  the  above  diagram. 

-  Action  connectors  such  as  A,B,C,  and  D  above. 

-  Emanating  from  Node  B  are  two  parallel  paths  or  branches.  Any 
number  of  branches  are  permitted. 

-  Action  names  such  as  ACT-I,  ACT-2, ....ACT-5  which  are 
accomplished  on  a  particular  branch. 


-  The  procedure  whereby  a  user  defines  the  network  path  selection. 
Examples  are  the  D  represents  "DO"  the  task  specified,  and  the  E 
means  "Either"  do  ACT-2  or  ACT-3.  Fifteen  different  single 
character  user  defined  modes  are  acceptable. 

-  The  .6  means  60%  of  the  time  ACT-2  is  done;  .4  means  40%  of  the 
time  ACT-3  is  done.  Several  of  the  acceptable  selection  modes  have 
parameters. 


FIGURE  4-2.  NETWORK  TERMS  DEFINITIONS 


b.  Example  Networks 


The  simplest  mission  network  contains  three  tasks;  a  pre-sortie,  sortie  and  post-sortie  task,  while  the 
simplest  activity  network  contains  only  one  task.  Figure  4-3  illustrates  an  example  of  a  simplified  task 
network  for  a  mission. 


In  Figure  4-3,  the  sortie  task  is  the  series  successor  to  the  tow  task  and  the  drop  ordinance  is  a  parallel 
task  to  the  sortie  task.  The  description  of  any  network  of  tasks  is  flexible  in  that  it  can  be  described 
by  the  user  to  any  degree  of  simplicity  or  complexity  desired.  One  feature  permits  the  network  to  be 
designed  in  sections,  thereby  reducing  the  complexity  and  size  of  the  network  input  data.  A  separate 
section  which  is  utilized  in  more  than  one  place  in  the  total  network,  as  Section  M  was  in  Figure  4-3, 
can  thus  be  defined  only  once  and  called  from  several  locations  within  the  network.  In  the  example, 
this  might  be  a  maintenance  action  or  actions  possible  in  both  pre-  and  post-sortie  periods  of  time. 
The  size  of  these  sections  is  not  limited. 

Another  use  of  sectioning  is  based  upon  the  fact  that  once  called,  all  actions  within  the  section  must 
be  complete  prior  to  continuing  processing  of  the  network  from  which  the  cadi  was  made.  In  Figure  4- 
3,  Section  W  has  two  tasks  in  parallel,  Inspect  and  Weapons  Load.  Both  of  these  tasks  must  be 
completed  prior  to  returning  to  the  maun  network  and  doing  the  tow  task. 


Network  Entry 


During  the  simulation,  task  network  processing  is  started  by  defining  an  entry  point  to  the  network  and 
mission  type  that  will  trigger  this  initial  entry.  In  Figire  4-3,  Node  A  is  this  entry.  Each  entry 
generates  an  explicit  network  identifier  which  has  associated  with  it  an  aircraft  or  part  resource  that 
is  controlled  by  the  network  until  its  processing  is  completed  and  the  associated  part  is  released.  The 
network  identification  is  established  to  permit  a  series  of  tasks  to  generate  new  series  of  tasks 
involving  different  resources  without  losing  the  relationship  to  the  generating  network.  This  is 
exemplified  by  repair  of  an  aircraft  generating  a  reparable  to  the  shop,  the  repair  of  the  reparable 
generating  repair  of  a  sub-assembly,  etc. 
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d.  Selection  Modes 

The  processing  of  each  task  in  the  network  is  determined  bv  a  selection  mode  defined  in  the  input  data 
wh.ch  may  specify  one  of  15  options.  These  options  include  modes  A,B,C,D,E,F,G,H,I,3,K,R,S,T,  and 
U.  These  modes  can  be  basically  sub-divided  into:  those  that  are  discrete  functions  (B,C,D,  and  R), 
those  that  are  probabilistic  in  nature  (A,E,  and  G),  those  used  to  control  mission  timing  within  the 
j  model  (S),  and  those  that  deal  with  specific  model  features  (F,H,I,3,K,T,  and  U). 

The  main  module  is  designed  to  permit  utilization  of  any  of  these  network  selection  mode  options. 
They  provide  the  desired  flexibility,  selection,  and  control  of  the  scenario  chosen  by  the  user.  The 
network  feature  of  the  main  module  provides  a  means  for  simulating  a  large  variety  of  weapon  systems 
and  operational  environments. 

Each  selection  mode  is  defined  as  follows: 

(1)  Mode  A  -  Non  mutually  exclusive  Probability  -  This  A  or  "any"  selection  mode  is  the 
option  used  to  select  one  or  more  of  several  parallel  branches  in  the  network,  each  of  which,  involves 
an  independent  probability  of  accomplishment.  This  would  allow  determination  of  which  parts  of  all 
possible  parts  of  an  assembly  failed  when  mechanism  is  not  utilized  for  the  individual  parts.  Selection 
possibilities  will  be  that  arv^  or  all  of  the  parallel  branches  might  be  taken,  or  possibly  none.  Since 
probabilities  are  independent,  they  do  not  have  to  sum  to  any  particular  value.  The  APROB  change 

i  card  may  be  used  to  change  the  probability  of  a  specific  A  selection  mode  branch  at  any  point  in  time 
t  during  the  simulation.  See  also  the  "A,  E,  and  G  Selection  Mode  Relationship"  discussion. 

(2)  Mode  B  -  Constrained  by  prior  tasks  -  A  branch  is  considered  constrained  if  it  cannot 

be  started  until  a  number  of  preceding  tasks  have  been  completed.  The  preceding  tasks  would  normally 
be  indicated  as  parallel  tasks,  each  of  which  leads  to  the  task  in  question.  This  selection  option  on  a 
task  indicates  that  all  tasks  leading  directly  to  it  must  be  completed  before  an  attempt  is  made  to 
start  it.  Failure  to  use  this  option  would  allow  the  constrained  task  to  be  started  as  often  as  there  are 
tasks  leading  to  it,  so,  it  is  necessary  to  use  this  selection  mode  whenever  more  than  one  task,  all  of 

which  will  be  done,  lead  to  the  same  task.  The  tow  task  in  Figure  4-3  is  an  example  of  this  type  of 

task  and  if  the  tasks  in  Section  W  (Inspect  and  Weapons  Toad)  were  in  the  main  network  instead  of  the 
call  section  the  tow  task  would  have  been  input  as  mode  B.  Caution:  Where  there  exists  a  possibility 
of  another  task  being  parallel  to  this  constrained  task  processing  may  not  continue  through  it. 
Therefore,  the  definition  of  the  constraining  and  constrained  task,  should  be  made  within  a  small 
network  section  to  preclude  this  possibility.  As  an  example  of  this,  on  Figure  4-3,  the  constrained  tow 
task  and  the  inspect  and  weapons  load  tasks  would  be  input  as  a  separate  section.  Please  note  that  if 
the  call  section  W  contains  only  the  Inspect  and  Weapons  Load  task  processing  would  also  be  proper, 
since  the  entire  call  section  itself  must  be  complete  prior  to  continuing  in  the  main  network.  Hence,  a 
call  section  most  often  does  the  same  thing  as  a  B  mode  and  is  the  preferred  way  of  handling 
constraining  situations.  If  B  mode  is  used,  do  it  within  a  call  section  and  be  careful. 

(3)  Mode  C  -  Network  Section  Selection  -  This  C  or  "call"  option  permits  the  user  to 

describe  the  task  network  in  sections  to  eliminate  duplication  of  network  data  and  call  the  section 
from  any  place  in  the  networks.  An  example  of  a  section  is  shown  in  Figure  4-4. 

In  Figure  4-3,  Section  M  is  a  network  of  maintenance  tasks  common  to  two  points  in  the  general 
network.  Upon  completion  of  the  pre-flight,  Section  M  is  called  and  upon  completion  of  all  tasks  in 
Section  M,  return  is  made  to  the  Call  Section  W  task  of  the  general  network.  A  similar  action  is 
performed  after  post-flight.  This  is  a  powerful  and  effective  tool  for  network  simplification  and 
controlled  network  processing.  Figure  4-5  is  a  partially  expanded  view  of  Section  M  and  figure  4-4. 
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V. 


FIGURE  4-4.  EXAMPLE  OF  A  SECTION 


(4)  Mode  D  -  "Do"  the  task  -  This  option  is  used  when  there  is  no  question  of  selection. 
When  this  mode  is  used,  it  means  no  criterion  is  required  to  select  whether  or  not  the  task  is  done.  It 
is  always  done  when  it  is  addressed  by  a  preceding  task. 

(5)  Mode  E  -  Mutually  Exclusive  Probability  -  This  E  or  "Either"  selection  mode  is  the 
option  used  to  select  only  one  of  several  possible  parallel  tasks  in  the  network.  This  option  allows  a 
selection  such  as  base  or  depot  repair,  utilizing  the  NRTS  percent  to  make  the  selection.  Since  the 
probability  values  are  mutually  exclusive,  all  possibilities  should  be  accounted  for  and  the  sum  of  the 
probability  values  from  the  same  node  must  sum  to  exactly  1.0  or  less.  When  one  branching  possibility 
is  to  do  nothing,  it  can  be  eliminated  i.e.  the  sum  would  be  less  than  1.0.  A  restriction  when  using  this 
mode  is  to  not  mix  two  sets  of  E  branches  emanating  from  the  same  node.  The  EPROB  change  card 
may  be  used  to  change  the  probability  of  a  specific  E  selection  node  branch  at  any  point  in  time  during 
the  simulation.  See  also  the  "A,  E,  and  G  Selection  Mode  Relationship"  description. 

(6)  F  Mode  -  Failure  Mode  Selection  -  This  F  or  "Failure"  option  indicates  that  task 
accomplishment  will  be  determined  by  a  failire  clock  associated  with  some  resource  farther  along  in 
the  network.  During  troubleshooting  in  real  life,  a  particular  check  or  task  will  give  an  indication  of 
whether  an  assembly  is  serviceable  or  not  and  will  indicate  whether  to  proceed  with  further  checks  on 
the  unit.  This  failure  selection  option  indicates  to  the  main  module  that  the  task  in  question  is  of  that 
type,  i.e.,  it  will  be  done  if  it  leads  to  the  discovery  of  a  failire.  If  there  is  no  failire  of  a  resource 
along  this  path,  then  the  tasks  with  this  selection  option  leading  to  the  potential  failure  task  will  not 
be  done.  Thus,  it  is  the  failire  mechanism  which  determines  if  a  task  is  to  be  selected,  and  it  is  this 
selection  option  which  determines  which  tasks  are  involved  and  subject  to  selection.  At  least  the  first 
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tasks  in  Section  M  would  have  this  option.  They  would  not  be  done  unless  there  is  a  malfunction  of 
some  type  further  on  in  the  network.  If  none  of  the  three  tasks  in  Figure  W  were  selected,  the  section 
•  would  be  complete  and  processing  wcuid  return  to  the  main  network.  If  any  of  the  three  tasks  are 
•  selected,  processing  of  all  following  tasks  will  be  completed  prior  to  return  to  the  main  network.  See  a 
description  of  the  Failure  Mechanism  in  this  section 

/  \ 


V 


FIGURE  4-5.  SECTION  M  (incomplete  -  See  Figure  4-4) 


(7)  G  Mode  -  Non  Mutually  Exclusive  Probability  -  The  G  or  "Get"  at  least  one, 
Selection  Mode  is  essentially  the  same  as  the  A  mode  with  a  slight  rule  modification.  Remember  that 
when  processing  a  parallel  set  of  As,  the  rule  is  that  any,  all  or  possibly  none  of  the  branches  may  be 
taken,  depending  on  the  individual  random  numbers  drawn.  The  G  selection  differs  in  two  respects. 
First,  if  these  same  A  tasks  were  instead  marked  G,  given  an  absolute  value,  and  none  were  selected, 
then  the  model  would  recycle  (take  another  set  of  random  draws)  until  at  least  one  G  task  was  chosen. 
Secondly,  as  will  be  demonstrated  in  the  portion  of  this  section  titled  "A,  E,  and  G  Selection  Mode 
Relationships",  the  G  selection  mode  is  statistically  different  than  A  when  considering  the 
independence  of  failures.  In  addition,  use  of  the  G  mode  will  definitely  increase  simulation  run  time 

I  particularly  if  small  G  selection  parameters  are  used.  The  only  restriction  on  use  of  the  G  mode  is 
that  if  it  is  used  at  a  particular  juncture/node,  then  all  tasks  emanating  from  that  juncture  must  also 
be  G  selection  modes.  The  GPROB  change  card  may~Ee  used  to  change  the  probability  branch  at  any 
!  point  in  time  during  the  simulation.  Refer  also  to  AFMSMET  Report  78-2,  "The  G  Selection  Mode  Its 
j  Independent  and  Dependent  Use." 

(8)  H  Mode  -  Halt  Mechanism  Controlled  -  The  H  or  "Halt"  mode  acts  like  the  F  mode 
except  in  the  reverse.  Recall  that  if  a  failire  clock  has  breached  for  a  particular  F  task,  that  task  will 
be  done.  If  a  HALT  clock  has  breached  for  a  particular  H  task,  the  processing  of  that  particular  task 
and  the  subsequent  network  tasks  will  Halt  at  that  point.  Consider  the  H  as  a  failure  generated 
stopping  point  in  the  particular  leg  of  the  network  being  processed.  See  description  of  the  Halt 
mechanism  in  this  section  for  details. 


(9)  1  Mode  -  Cannibalization  Data  Mode  -  The  I  or  "Ignore"  selection  mode  is  used  in 
conjunction  with  the  cannibalization  mechanism.  It  is  used  only  on  tasks  that  consume  a  part  and 
indicate  to  the  cannibalization  mechanism  that  the  part  being  consumed  should  be  included  in  the  list 
of  cannibalized  parts.  It  also  tells  the  normal  processing  to  ignore  the  task  time  when  the  part  is 
received  from  supply.  See  Cannibalization  Mechanism  Description  in  this  section  for  detail  of  use. 

(10)  3  MODE  -  Aircraft  Timing  Switch  -  The  3  or  "3ump"  selection  mode  is  used  to 
partially  activate  the  "Aircraft  K  Timing  Switch"  which  in  turn  controls  the  processing  of  the  3  and  K 
selection  mode  tasks.  See  Selection  mode  K  and  U,  and  the  Aircraft  K-Timing  Switch  descriptions  in 
this  section. 
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(11)  K  MODE  -  Aircraft  Time  Switch  -  The  K  or  "Kill"  selection  mode  is  used  to  fully 
activate  the  "Aircraft  K  Timing  Switch"  which  in  tirn  controls  the  processing  of  the  3  and  K  selection 
mode  tasks.  See  Selection  mode  3  and  U,  and  the  Aircraft  K-Timing  Switch  descriptions  in  this 
section. 

(12)  R  MODE  -  Resource  Availability  Mode  -  The  R  or  "Resource"  mode  permits  the 
placing  of  tasks  on  parallel  network  branches  originating  at  a  common  node  and,  based  upon  resource 
availability,  having  only  one  of  the  tasks  process.  This  is  accomplished  by  defining  R  as  the  selection 
mode  for  these  branches.  The  R  mode  functions  very  much  like  the  G  mode,  but  very  important 
differences  exist. 

The  G  mode  checks  a  pet  cent  parameter  to  determine  which  parallel  task  or  tasks  will  be 
accomplished.  The  R  mode  sequentially  checks  each  parallel  branch  for  the  availability  of  all  the 
resources  required  by  the  individual  tasks.  If  the  resources  are  available,  only  that  task  is  started.  No 
other  parallel  tasks  will  start. 

The  G  mode  will  make  sufficient  passes  through  tlie  parallel  tasks  until  at  least  one  is  started.  The  R 
mode  will  make  one  pass.  If  none  can  be  started,  the  first  task  will  be  backordered.  Note  again  that 
only  one  of  the  parallel  tasks  will  be  started,  therefore,  once  the  backordering  takes  place,  only  this 
backordered  task  (the  first  of  the  series)  will  be  considered  for  further  processing. 

The  user  must  define  only  R  selection  modes  in  parallel  or  R  modes  mixed  with  D  modes.  Any  other 
combination  is  illegal  and  will  cause  a  fatal  error  message  to  be  printed  by  the  Input  Module. 

The  parallel  R  selection  modes  must  not  be  placed  directly  in  the  main  line  network  such  that  each 
branch  leads  to  a  sortie  task.  This  will  cause  an  error  message  from  the  Input  Module  network  search. 
This  R  mode  option  should  only  be  used  within  a  call  section,  post-sortie,  or  activity  processing 
network. 

(13)  $  Mode  -  Sortie  Task  Timing  Control  -  This  S  or  "Sortie"  option  is  assigned  to  the 
sortie  task,  a  task  whose  starting  time  is  to  be  controlled  by  the  mission  data.  When  this  option  is 
encountered  on  a  task,  mission  data  is  referenced  in  order  to  establish  the  earliest  possible  starting 
time.  If  the  preceding  task  is  completed  and  other  mission  requirements  are  satisfied,  the  task  will  be 
started. 


(14)  T  Mode  -  Trigger  Node  Controlled  -  This  T  or  "Trigger"  selection  mode  is  used  for 

the  Configuration  Management  of  Internal  Equipment  on  an  aircraft.  It  is  treated  as  a  do  task  for 
network  processing  purposes  but  will  trigger  either  the  loss  or  gain  of  some  internal  piece  of 
equipment.  See  Configuration  Management  -  Interned  Configuration  Mechanism  description  in  this  , 
section.  Note:  When  dealing  with  parallel  branches,  only  1  T  can  be  used  and  it  must  occur'W  the  J 
Form  ll's.  • 

(15)  U  Mode  -  Aircraft  Timing  Switch  -  The  U  or  "Unschedule  and  Unset"  mode  is  used  to 
deactivate  the  "Aircraft  Timing  Switch"  after  it  has  been  turned  fully  on  and  a  reset  for  it  has  been 
scheduled.  See  Selection  mode  3  and  K  and  the  Aircraft  Timing  Switch  descriptions  in  this  section. 

4.  Control  Table/Network  Relationship 

The  Control  Table  used  by  the  main  simulation  model  is  just  a  tabularization  of  the  input  network  on 
Form  11.  It  differs  from  the  input  data  by  using  a  different  structure  and  numeric  codes  rather  than 
alphabetic  names  and  codes.  To  an  LCOM  II  user,  the  terms  "Network"  and  "Control  Table"  should  be 
synonymous.  Their  exact  data  relationship  is  described  in  the  Chapter  III  description  of  Control  Table 
output. 

5.  Task  Description 

Each  task  used  in  the  network  is  individually  defined  as  a  job  with  requirements  for  time  and  resources. 
The  same  task  may  be  used  in  several  places  in  the  complete  network,  but  will  require  only  one 
description.  All  the  tasks  are  collected  by  the  Input  Module  into  a  set  called  the  task  dictionary. 
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The  type  of  task  specified  controls  the  collection  of  processing  statistics  into  the  proper  categories  of 
work.  The  input  priority  controls  the  initial  task’s  priority  assignments.  See  Priority  System  featire 
description. 

The  *ime  requirements  for  each  task  are  described  by  specifying  a  mean,  variance,  and  distribution 
type.  One  of  seven  standard  or  an  empirical  distribution  can  be  selected.  See  Chapter  III, 
Distributions,  for  the  mean  and  variance  field  requirements  for  each  distribution  type.  Using  this  task 
duration  data,  the  main  module  randomly  selects  for  each  task  processed,  a  task  duration  time  from 
the  specified  distribution.  Requirements  for  resources  are  defined  in  a  man  ler  to  indicate  the 
relationship  of  the  resources  to  the  specific  task.  Four  distinct  options  are  available  to  the  user  in 
describing  this  relationship.  A  brief  description  of  each  follows.  The  Consume  and  Generate  options 
are  described  in  detail  as  separate  features  later  in  this  section. 

a.  Temporary  Use.  The  resource  is  normally  used  during  the  entire  task  duration  and,  upon 
completion  of  the  task,  is  retimed  to  a  pool  for  use  by  other  tasks.  With  this  option,  use  of  such 
resources  as  men  and  equipment  can  be  described. 

b.  Consume.  The  resource  becomes  an  integral  part  of  the  item  being  processed,  such  as, 
an  aircraft  assembly  becoming  part  of  the  aircraft  and  the  assembly  is  not  returned  upon  completion  of 
the  task.  All  consumable  resources  such  as  assemblies  and  sub-assemblies  are  described  using  this 
option.  See  the  Consume  feature  description  for  more  details. 

c.  Generate.  A  resource  is  generated  by  the  specific  task  for  processing  as  a  separate  item, 
e.g.,  assembly,  subassembly,  etc.  This  action  is  specified  by  defining  a  resource  as  an  associated 
resource  on  the  task.  The  generate  task  and  all  tasks  subsequent  to  it  (until  another  generate)  will 
process  the  associated  resource.  The  portion  of  the  network  beginning  with  the  generate  task  no 
longer  deals  with  or  impacts  upon  the  (next  higher  indenture)  resource  that  was  being  processed  at  the 
time  the  generate  task  was  reached.  For  each  generate  task  processed  in  succession,  the  main  module 
in  effect,  begins  the  processing  of  the  next  lower  indenture  resource.  See  the  Generate  feature 
description  for  more  details. 

d.  Task  Specific  Resource  Substitution.  Alternate  manpower  resources  can  be  specified  on 
separate  sets  of  task  definitions.  Refer  to  the  Resource  Substitution  feature  description  in  this 
chapter  for  a  complete  description  of  how  this  option  fits  into  the  overall  Resource  Substitution 
feature. 

Tasks  are  defined  on  Form  12  and  12As.  See  Chapter  VIII  for  the  details  of  defining  tasks. 

6.  Resource  Description 

Aircraft,  men,  parts,  equipment,  and  their  resources  are  an  integral  part  of  the  LCOM  II  Simulation 
Software  input  requirements.  During  the  operation  of  the  Main  Module,  these  resources  can  be 
consumed,  (e.g.,  aircraft  and  parts)  used  and  returned  to  a  pool  (e.g.,  men  and  equipment),  or  generated 
(e.g.,  reparable  units).  Resources  are  grouped  into  four  categories  or  types  and  referred  to  as  such  for 
proper  data  collection.  The  categories:  (1)  aircraft,  (2)  parts,  (3)  personnel,  and  (4)  equipment 
Multiple  resources  in  each  category  can  be  defined. 

The  number  of  resources  that  can  be  defined  is  basically  unlimited,  such  that,  the  user  may  define 
resources,  particularly  parts,  down  to  and  including  bits  and  pieces  if  desired,  or  the  parts  can  be 
a88regated  at  any  desired  level.  Resource  authorized  quantities  can  also  be  substantially  high. 

Multiple  resource  substitutions  are  specified  at  the  time  resources  are  defined.  See  Resource  Sub¬ 
stitution  feature  description  in  this  chapter. 


7.  Generating  Resources 


Resources  are  generated  in  LCOM  II  in  two  ways:  at  the  beginning  of  the  simulation,  and  by  processing 
a  task  in  the  task  network.  Generation  is  the  establishment  of  a  physical  record  to  represent  the 
resource  and  adjusting  its  on-hand  quantity.  In  LCOM  II  there  are  two  distinct  types  of  resources, 
aircraft  and  non-aircraft.  Non-aircraft  may  be  designated  as  men,  age,  parts,  or  facilities,  but  for  ail 
practical  purposes,  they  are  treated  in  the  main  module  similarly.  These  two  types  are  discussed 
separately  below. 

a.  Aircraft 

At  the  beginning  of  the  simulation  a  separate  record  is  generated  for  each  authorized  aircraft.  When 
generated,  the  default  configuration  (first  one  defined  on  Form  17  for  that  aircraft)  is  used  unless  the 
user  specifies  another  one  with  a  STORAC  change  card.  These  records  are  maintained  throughout  the 
simulation  except  when  the  aircraft  are  removed  entirely  from  the  simulation.  The  authorized 
quantity  of  aircraft  will  always  equal  the  number  of  valid  aircraft  records  in  the  simulation  and  the  on- 
hand  quantity  will  be  equal  to  those  aircraft  not  currently  in-use,  i.e.,  not  processing  within  the 
network.  The  AUTH  and  AUTHA  change  cards  can  be  used  at  time  =  0.0  to  increase  or  decrease  this 
authorization. 

Defining  a  task  on  Form  12  to  generate  an  aircraft  is  done  by  placing  an  *  in  col  29  and  specifying  the 
aircraft  name  as  the  associated  resource  (col  30-35).  This  task  can  have  other  non-aircraft  resources 
as  required  resources  (col  37-63).  When  reaching  this  task  in  the  network,  the  main  module  will 
generate  the  aircraft  record  and  permit  it  to  process  the  task  itself  and  all  subsequent  tasks  until  end 
of  network,  when  it  will  increase  the  on-hand  quantity.  When  generated,  the  default  configuration 
(first  one  defined  on  Form  17  for  that  aircraft)  is  used  unless  the  user  specifies  another  one  with  a 
GENRAT  change  card.  Also,  this  aircraft  has  its  own  separate  failure  mechanism.  At  end  of  network, 
the  aircraft  is  stored  as  available  in  this  configuration,  and  the  aircraft  record  is  not  released. 

The  configuration  specified  on  the  GENRAT  change  card  applies  to  all  generations  of  the  specific 
aircraft. 

b.  Non-Aircraft 

At  the  beginning  of  simulation,  non-aircraft  resources  are  not  actually  generated,  but  their  on-hand 
quantity  is  set  equal  to  the  amount  authorized.  Throughout  the  simulation,  these  non-aircraft 
resources  have  no  individual  records  except  while  they  are  processing  a  network.  The  AUTH,  AUTHA, 
and  SAUTH  change  cards  can  be  used  at  time  =  0.0  to  increase  or  decrease  this  authorization.  After 
simulation  has  started,  the  AUTH  card  can  only  be  used  to  increase  the  authorized  and  on-hand  quanti¬ 
ties  and  will  be  effective  immediately  upon  reading  the  change  card;  the  SAUTH  card  can  be  used  to 
either  increase  or  decrease  resources  on  a  shift,  but  the  change  to  the  on-hand  quantity  will  not  be 
effective  until  the  next  time  the  shift  specified  begins. 

Actual  generation  of  a  non-aircraft  record  is  done  by  processing  a  task  defined  on  Form  12  with  an  *  in 
col  29  and  the  resource  name  as  the  associated  resource  (col  30-35).  Only  non-aircraft  resources  can 
be  specified  as  required  resources  (col  37-63).  This  generated  record  will  be  used  to  process  this  non¬ 
aircraft  resource  until  it  reaches  end  of  network.  At  that  time,  the  record  is  destroyed  and  the  on- 
hand  quantity  increased. 

To  sum  up  -  Aircraft  records  are  generated  and  maintained  throughout  the  simulation  until  specifically 
removed.  Non-aircraft  records  exist  only  while  processing  a  section  of  network.  Both  aircraft  and 
non-aircraft  resources  are  released  (on-hand  increased)  to  the  simulation  upon  completion  of  their 
network  processing. 

8.  Consuming  Resources 

Resources  are  consumed  during  simulation  by  processing  a  task  specifying  a  particular  consumption  or 
by  reductions  in  authorizations  thru  the  snift  mechanism.  Aircraft  are  also  consumed  thru  attrition. 
(See  Attrition  Feature  description.) 
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a.  Aircraft  Resources 

To  consume  an  aircraft  on  a  task,  it  must  be  defined  on  Form  12  with  the  following  characteristics. 
First,  there  must  be  no  associated  resource  on  the  task,  e.g.  no  *  in  col  29.  Second,  the  only  required 
resources  in  cols  37-63  must  be  the  aircraft  and  a  "single"  consume.  Third,  no  other  required  resources 
including  time  must  appear  on  the  task. 

As  in  the  generation  of  aircraft,  the  main  module  needs  to  know  an  aircraft  configuration.  The 
configuration  is  assumed  to  be  the  first  one  defined  on  Form  17  for  the  specific  type  aircraft  unless 
the  user  has  specified  another  one  with  a  C.ONSUM  change  card.  (See  Chapter  VII,  Change  Card 
description.)  This  configuration  applies  to  all  consumptions  of  the  specific  type  aircraft. 

If  an  aircraft  of  desired  type  and  configuration  is  available,  the  model  most  effectively  removes  the 
aircraft  from  the  simulation  by  reducing  the  orvhand  by  one  and  removing  the  aircraft  record.  A 
dummy  task  is  inserted  for  the  consume  task  and  network  processing  continues. 

If  an  aircraft  of  the  desired  type  and  configuration  is  not  available,  a  single  dummy  task  activity 
demanding  the  aircraft  is  created  and  backordered.  This  activity  when  satisfied  with  the  aircraft 
effectively  re-enters  the  network  at  the  point  in  the  network  subsequent  to  the  task  consuming  the 
aircraft.  The  aircraft  record  is  removed  from  the  simulation  and  the  on-hand  quantity  is  reduced  by 
one. 

b.  Non- Aircraft  Resources 

To  consume  a  non-aircraft  resource  it  must  be  used  on  a  task  (defined  on  Form  12)  as  a  required 
resource  with  a  'C'  in  the  proper  consume  column  (43,  52,  or  61).  No  restrictions  are  made  except 
where  cannibalization  is  involved.  If  the  task  is  used  in  the  network  with  an  I  selection  mode,  only  one 
type  resource  can  be  consumed  on  the  task  and  then  only  by  a  quantity  of  one.  Other  norv  aircraft 
resources  can  be  identified  as  resources  required  (cols  37-63)  or  any  resource  can  be  identified  as  an 
associated  resource  (col  29-35). 

Since  non-aircraft  resource  records  do  not  exist,  i.e.,  there  is  really  no  resource  to  consume.  Only  the 
on-hand  quantity  is  reduced  by  the  consume  amount.  If  any  resource  required  on  a  task  is  not 
available,  the  task  is  backordered.  When  available,  the  task  starts  and  upon  completion,  it  doesn't 
release  the  resource  back  to  the  system,  i.e.,  on-hand  is  not  increased. 

9.  Failure  Mechanism 

a.  General  Description.  The  methodology  for  inducing  resource  failure  into  the  simulator  is 
designed  to  provide  the  greatest  possible  flexibility  in  use  of  this  failure  mechanism. 

The  basic  mechanism  can  be  thought  of  as  a  clock  that  is  utilized  to  trigger  action  within  the  network. 
This  clock  is  first  set  to  some  value,  random  variate  or  constant,  then  successively  decremented  by 
defined  amounts  when  processing  certain  network  tasks,  until  the  value  is  zero.  On  reaching  zero  a 
failire  of  some  sort  has  occurred,  information  is  stored  concerning  where  in  the  network  this  clock  was 
referenced,  the  clock  is  reset  in  a  manner  similar  to  the  original  setting,  and  later  successively 
decremented  for  the  next  failure. 

Clocks  can  represent  and  be  driven  by  almost  any  failure  criteria  such  as,  number  of  aircraft,  sortie 
time,  resource  operating  time,  absolute  time,  etc.,  limited  only  by  the  users'  ingenuity. 

b.  Setting  the  Clocks 

Each  clock  is  defined  on  Form  13  in  terms  of  its  mean,  variance,  and  distribution  type.  The  model  uses 
these  parameters  to  initially  set  and  reset  the  clocks.  With  the  exception  of  the  triangular 
distribution,  all  standard  and  empirical  distributions  can  be  used. 

In  order  to  simulate  a  start-up  condition,  where  all  clocks  are  not  at  their  maximum  value  at  time  =  0, 
all  docks  are  multiplied  by  a  random  number  between  0  and  1.0,  i.e.,  initial  value  will  be  a  percent  of 


4-14 


initial  dock  setting.  The  value  of  all  dock  parameters  can  be  obtained  by  setting  SWICH  // 1 1  to  on 

(.0. 

c.  Using  the  Clocks 

Clocks  are  used  within  the  networks  (Form  11)  by  spedfying  an  F  selection  mode  and  using  the  dock  as 
the  parameter.  The  user  can  use  a  dock  with  an  F  selection  parameter  in  more  than  one  place  in  the 
network.  When  a  dock  reaches  zero,  information  about  all  the  locations  in  the  network  concerned 
with  the  dock  are  used  to  control  the  network  processing.  This  information  is  provided  to  the  resource 
whose  network  processing  caused  the  dock  or  docks  to  break. 

d.  Decrementing  the  Clocks 

(1)  Each  task  in  the  network  assigned  to  decrement  a  dock  or  list  of  docks  is  identified 
on  Form  14.  These  tasks  would  have  been  previously  defined  on  Form  12  and  used  in  the  networks  on 
Form  11. 

(2)  The  spedfic  docks  that  are  to  be  decremented,  the  decrement  mode,  and  value  of 
the  decrement  are  spedfied  on  Form  14. 

(3)  Any  desired  combination  of  failure  setting  and  decrementing  can  be  included  in  a 
simulation  such  as  listing  the  same  failure  clock  under  two  different  decrement  tasks  and  values. 
However,  tasks  can  only  be  identified  once  on  Form  14  and  can  only  decrement  by  one  mode. 

e.  Controlling  Network  Processing  (F  task  stringing) 

(1)  Once  the  value  of  the  dock  reaches  zero,  a  failure  has  occurred  and  the  network 
processing  mechanism  for  the  aircraft  must  be  informed  which  network  F  task  gates  are  now  opened  by 
this  failure.  Here  F  task  stringing  comes  into  use. 

(2)  F  task  stringing  is  defined  as:  sequential  tasks  in  the  network  being  controlled  by 
the  same  dock.  A  task  in  the  network  that  is  controlled  by  a  failire  dock  (specified  as  the  failire 
parameter)  could  be  preceded  by  another  task  with  a  selection  mode  F,  but  contains  no  dock 
parameter  (uncontrolled).  The  software  effectively  links  the  controlled  and  uncontrolled  tasks  by 
maintaining  pointers  to  these  tasks  in  the  individual  aircraft  failure  set  called  flow  queue  (FLWQ).  All 
F  casks  within  a  network  section,  whether  it  is  controlled  or  uncontrolled,  will  be  linked  together  under 
control  of  the  final  F  task  with  dock  parameter  in  the  string  of  F  tasks.  See  Figure  4-7. 

(3)  All  Properly  Linked  Network  Locations  induding  the  triggering  F  location  are  stored 

in  the  FLWQ  owned  by  the  aircraft's  network  (NET)  record.  During  network  processing  for  the  owner 
aircraft,  when  a  task  in  the  control  table  coded  F  selection  is  reached,  the  set  FLWQ  is  searched  for 
the  Network  Location  under  consideration.  If  lound  in  FLWQ,  processing  will  take  place;  otherwise, 
processing  of  that  leg  of  the  network  stops  at  this  point.  When  the  resource  entering  the  network 
(Forms  20)  and  all  of  the  non-aircraft  resources  generated  a  result  of  its  network  processing  have 
completed  their  network  processing,  the  set  FLWQ  is  released.  This  means  that  the  F  tasks  controlled 
by  a  particular  dock  should  follow  any  tasks  that  decrement  the  dock;  otherwise,  those  tasks  cannot 
be  processed.  ^ 

10.  Halt  Mechanism  -  H  Selection  Mode 

The  H  selection  mode  utilizes  the  Failure  Mechanism  Structure,  but  uses  it  in  the  reverse  way  the  "F" 
mode  does,  itecall  that  if  a  failire  dock  has  breached  zero  for  a  particular  F  task,  that  the  task  will 
be  done.  When  a  HALT  dock  breaches,  the  particular  network  location/s  controlled  by  that  H  dock 
will  not  be  processed,  thus  all  subsequent  network  tasks  will  also  not  be  accomplished.  Multiple 
network  locations  can  reference  the  same  H  dock  for  their  control. 

Consider  the  H  as  a  failure  generated  stopping  point  in  a  particular  leg  of  the  network  being  processed. 
As  implied  here,  the  H  selection  is  handled  by  the  user  just  like  that  of  the  F  with  one  exception;  H 
tasks  must  be  independent  of  each  other,  that  is  every  H  selection  mode  must  have  an  H  dock 
assodated  with  it.  This  ensures  that  H  taste  will  not  be  strung  out  like  Fs.  See  Figure  4-6. 
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Example  A 


r  CLOCKA 


Example  B 


#A  -  This  network  is  valid  since  tasks  3  and  5  are  dependent  on  the  single  F  clock  at  task  7. 

f/B  -  This  network  is  valid  since  there  is  complete  independence  between  the  H  clocks  for  tasks  3,  5, 
and  6.  No  stringing  of  Hs  with  Fs  or  other  Hs  is  permitted.  Task  4  and  5  will  not  string. 


FIGURE  4-6.  F/H  SELECTION  MODE  RELATIONSHIP 


Z'  Example  1  "X 

'In  this  example,  the  FLWQ  contains  data  to  control  network  processing  triggered  by  a  • 

failure  of  CLOCKA.  Tasks  at  locations  10  and  20  are  controlled  indirectly  by  this  clock 
as  they  are  coded  F  selection  mode  and  lead  directly  to  network  location  30.  Set  FLWQ 
contains  a  30,  20,  and  10.  If  CIOCKB  had  failed  the  FLWQ  would  contain  a  2S,  20,  and  10. 

If  both  had  failed  the  FLWQ  would  have  contained  30,  25,  20,  and  10  (no  duplicates). 


-c 
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Network  locations 
are  placed  in  FLWQ  of  Aircraft 


v  (CLOCK- B) 


_5fl_ 


F  (CLCCK-A) 


FLWQ  entries 
when  Clock- A 
fails 


Example  2 

_  _  ..  network  st _  ...  ... 

not  string  when  Clock-C  fails.  FLWQ  only  contains  a  20. 


F  Task  stringing  will  not  happen  between  network  sections.  In  this  example,  these  two 

p/s  mil  m »  uk*.  ru*L  n  r.n.  n  un  — _ ^  _  . _ 


F  (Clock-C) 


F  Task  stringing  will  be  accomplished  thru  ill  preceeding  F  Tasks,  even  those  with  valid 
clock  parameters. 


Clock-E's  failure  stringing  wxll  include  locations  40,  30,  20,  and  10  in  the  FLWQ 
Clock-D's  failure  stringing  will  include  locations  30,  20,  and  10  in  the  FLWQ. 


(Clock-D)  F  (Clock-E) 


Examp ’e  4 

Two  F  Tasks  in  parallel  cannot  lead  to  a  single  F  Task  controlled  or  uncontrolled  because 
the  model  has  no  way  of  knowing  which  way  to  string  back  Therefore,  this  networking 
is  illegal. 


Not*1  All  numbers  in  the  above  networks  represent  network  locations,  not  task  numbers 


FIGURE  4-7 _  F  TASK  STRINGING 
4^17 


11.  Shift  Mechanism 

The  shift  mechanism  utilized  in  the  model  is  a  feature  that  is  not  limited  to  just  describing  personnel 
shift  changes.  By  extension  of  the  data,  it  can  be  used  to  externally  control  any  resource  quantities 
other  than  aircraft  strength.  Form  16  is  used  to  input  shift  information.  See  Chapter  VIII  for  details 
of  inputting  the  data. 

The  mechanism  is  based  upon  the  concept  of  a  shift  pattern  which  is  best  described  by  an  example, 
shown  in  Table  4-1.  This  example  contains  the  following  data! 

Row  1  -  the  shift  identity  (positive  numbers)  and  the  cycling  value  (negative). 

Row  2  -  the  duration  (hours)  of  the  corresponding  shift  entered  in  Row  1. 

Row  3  -  the  authorized  quantity  of  a  specific  resource  (i.e.,  men)  during  the  corresponding  shift 
entered  in  Row  1. 


TABLE  4-1.  EXAMPLE  SHIFT  PATTERN  (5  DAYS  THEN  2  DAYS) 


1  2  3  4  5  6  7  8 


Shift  Identity 

Shift  Duration 

Authorized  Quantity 
(Man) 


The  example  is  read  as  follows: 

a.  Column  1,  Row  1,  indicates  this  is  shift  #1. 

Column  1,  Row  2,  indicates  that  shift  //I  is  8  hours  long. 

Column  1,  Row  3,  indicates  there  are  4  men  on  duty  during  shift  #1. 

b.  Columns  2  and  3  read  similar  to  Column  1  with  the  exception  of  a  different  shift  number 
and  fewer  men  on  duty. 

c.  Column  4  indicates  we  are  at  the  end  of  one  shift  pattern  and  must  repeat  the  pattern 
(Columns  1,  2,  <5c  3)  5  times  before  continuing  to  Columr.  5.  This  represents  a  5-day  work  week. 

d.  Columns  5,  6,  &  7  read  similar  to  Column  1.  Note  that  although  shifts  #1,2,  and  3  were 
repeated  5  times,  this  is  the  4th  different  shift  definition/identity. 

e.  Column  8  reads  similar  to  Column  4  indicating  we  mast  repeat  the  pattern  (Columns  5,  6, 
&  7)  twice.  This  represents  a  weekend. 


f.  With  no  additional  entries  in  the  table,  the  next  column  read  will  be  Column  1. 
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The  total  period  covered  by  the  shift  patterns  need  n->t  be  confirmed  to  seven  days  as  in  the  example 
but  can  be  anything.  The  example  data  in  Table  4-2  indicates  a  period  of  nine  days,  each  day  of  the 
first  seven  split  into  two  12-hour  shifts,  and  the  last  two  days  are  aggregated  into  one  48-hour  entr  y. 


TABLE  4-2.  EXAMPLE  SHIFT  PATTERN  (7  DAYS  THEN  2  DAYS) 


Shift  Identity 


Shift  Duration 


12.  Defining  Resources  That  Can  Enter  the  Networks 


Multiple  aircraft  can  be  defined  on  Form  13  by  using  the  normal  procedure  of  entering  the  resource 
name  and  defining  its  type  as  aircraft.  These  aircraft  are  automatically  entered  into  the  list  of  valid 
resources  that  can  externally  enter  the  networks.  This  aircraft  name  is  used  in  Columns  20-25 
(Aircraft  ID  Field)  on  Form  20.  Aircraft  can  process  either  Mission  or  Activity  requirements. 


Resources  other  than  aircraft  can  enter  the  networks  but  can  only  process  Activity  requirements. 
Entry  permission  is  done  by  placing  an  asterisk  in  Column  11  of  the  Form  13  data  record  defining  the 
non-aircraft  resources  and  using  that  resource  name  in  Columns  20-25  (Aircraft  ID  Field)  on  Form  20. 

The  Form  17  procedure  for  defining  mission  and  activity  processing  on  Form  17  is  described  in  Chapter 
VIII. 


1 3.  Tail-Number-Tracking  -  Aircraft  processini 


A  record  of  each  aircraft  within  the  simulation  model  is  maintained  from  the  first  time  the  aircraft 
becomes  part  of  the  simulation  until  it  leaves  the  simulation.  This  permits  a  tracking  of  the  aircraft 
processing  throughout  the  simulation,  so  that,  at  any  point  in  time,  the  most  recent  historical  aircraft 
actions,  configurations,  conditions,  or  usage  are  known.  This  is  generally  referred  to  as  tail-number- 
trarking  (TNT). 

The  TNT  capability  provides,  through  the  aircraft  records  described,  the  necessary  history  data  to 
permit  the  implementation  of  such  features  as  Configuration  Management,  the  outputting  of  the 
Realized  Flying  Schedule,  KTIME  switch  mechanism,  aircraft  tracking  (TRAKAC  change  card),  etc. 
TNT  aids  many  other  features  in  performing  their  functions.  No  change  in  input  data  is  required  to 
cause  the  tail-number-tracking  mechanism  to  operate  since  it  is  automatic. 

Within  the  simulation  aircraft  are  maintained  in  one  of  three  major  statuses;  (1)  available,  (2)  cocked, 
and  (3)  in-use.  The  available  and  cocked  are  those  aircraft  that  are  not  currently  processing  and  can 
be  assigned  to  mission  requirements.  These  two  statuses  and  their  impact  on  mission  assignment  will 
be  thoroughly  reviewed  under  the  Configuration  Management  feature  description. 


Tho  in-use  aircraft  arc  those  that  are  processing  within  the  networks.  In  order  to  jurthe-  define  wl<erc? 
and  under  what  condition  the  in-use  aircraft  are  processing,  the  in-use  status  is  subdivided  into  nme 
additional  conditions  or  sub- statuses.  However,  keep  in  mind  that  the  aircraft  are  still  maintained  in 
the  in-use  status.  The  aircraft  are  flagged  while  in  this  status  to  indicate  tlx?  cirreni  processing. 
Available  and  cocked  aircraft  although  maintained  as  such,  are  also  assigned  a  flag  value.  Table  4-3 
lists  all  these  aircraft  status  flags  and  provides  a  description  of  each. 

Many  aircraft  snapshot  reports  (i.e.,  BOSTAT,  IPSTAT,  MNSTAT,  and  QSTAT)  include  these  aircraft 
status  flags  as  an  output  item.  TNT  of  aircraft  processing  can  be  roadiiy  observed  a.  change  of  the 
aircraft  from  one  flag  value  to  another.  Table  4-4  lists  all  possible  flag  value  changes  and  provides  a 
reason  for  each  change. 


TABLE  4-3.  AIRCRAFT  STATUS  FLAGS 


Flag  Value 
0 
20 
40 


60 

80 

100 

101 

200 

250 

300 

400 

NA 


Status  Description 

Aircraft  is  available  for  a  mission  assignment  (pre-sortie  processing— required). 

Aircraft  is  cocked,  ready  for  immediate  mission  assignments. 

This  aircraft  has  completed  pre-sortie  task  processing,  but  not  enough  other 
aircraft  are  ready  to  start  sortie.  This  aircraft  will  wait  until  sufficient  air-.i  af  t 
are  available  or  until  the  mission  is  scrubbed. 

Pre-sortie  task  processing  complete  and  at  least  minimum  number  of  aircraft 
are  ready. 

.Aircraft  is  processing  pre-sortie  tasks  or  has  completed  them  and  mission 
has  been  cancelled  or  mission  has  flown  without  it. 

Processing  pre-sortie  tasks  towards  a  valid  mission. 

Processing  pre-sortie  tasks  towards  a  valid  mission  and  have  processed  at  least 
one  unscheduled  maintenance  task. 

Aircraft  processing  post-sortie  tasks. 

Activity  processing. 

Aircraft  is  flying. 

A  cocked  aircraft  processing  pre-sortie  tasks  for  a  mission  requiring  that  AC's 
current  configuration  as  its  take-off  configuration.  Actually,  processing  pre¬ 
sortie  portion  of  network  to  reach  sortie  task  but  task  times  are  all  zero  time 
delay. 

Not  applicable,  no  aircraft  record  exists. 


NOTE:  The  "in-use"  aircraft  status  contains  all  aircraft  with  flag  values  of  40  or  greater. 


TABLE  4-4.  AIRCRAFT  STATUS  FLAG  CHANGES 


FLAG  CHANGE 
0  -  100 
0-  100 
0 — NA 
0-230 
20  -  400 
20-  100 
20  -  250 
20 -NA 
40-60 
40  -  80 
60  -  300 
60  -  80 
SO  -  400 
80  -  20 

100  or  101  -  40 
100  or  101  -  80 
100  or  101  -  80 
200  -  NA 
200-0 
250  -  0 
250—20 
250—20 
300  -  200 
400  -  40 
400  -  80 
400  -  80 
NA  -  0 


REASON 

Satisfies  a  new  mission  request. 

Satisfies  an  existing  mission  request. 

Removing  an  aircraft  from  the  simulation  by  a  "consume". 

Satisfies  new/existing  activity  request. 

Satisfies  a  mission  request  (no  reconfiguration). 

Satisfies  a  mission  request  (reconfiguration). 

Satisfies  a  new/existing  activity. 

Removing  an  aircraft  from  the  simulation  by  a  "consume". 

Minimum  aircraft  requirement  is  ready. 

Cancel  time  is  reached  and  number  of  aircraft  less  than  minimum. 

At  or  after  scheduled  take-off  time  the  min.  or  max.  aircraft  were  ready. 
Aircraft  is  a  spare  and  the  mission  goes  without  it. 

Aircraft  at  sortie  task  satisfies  an  existing  mission. 

Aircraft  at  sortie  cannot  satisfy  a  mission  request. 

Individual  aircraft  becomes  ready  for  mission. 

Aircraft  not  at  sortie  task  and  mission  goes. 

Aircraft  not  at  sortie  task  and  mission  cancels. 

Removing  an  aircraft  from  the  simulation  by  attrition. 

Aircraft  post-sortie  processing  complete. 

Aircraft  activity  processing  complete. 

Aircraft  activity  processing  complete,  cocked  AC  released  as  picked  up. 
Alert  aircraft  replenishment  or  release  activity  processing  complete. 
Aircraft  lands. 

Aircraft  becomes  ready  for  a  mission. 

Aircraft  not  at  sortie  task  and  mission  goes. 

Aircraft  not  at  sortie  task  and  mission  is  cancelled. 

Adding  aircraft  to  the  system. 
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1 4.  Configuration  Management 

a.  General  Description 

Configuration  management  is  the  feature  whereby  users  of  LCOM  II  maintain  significant  external 
control  of  the  aircraft  usage.  This  control  considers  the  aircraft's  configuration  which  can  be  in  terms 
of  either  external  or  internal  configuration  or  both. 

external  configuration  is  normally  descriptive  of  the  ordnance  loading  of  an  aircraft  or  anything 
externally  mounted  that  could  change  the  use  characteristics  of  an  aircraft;  for  examp'e,  bombs, 
missiles,  racks,  etc.  Internal  configuration  refers  to  a  specific  piece  or  set  of  internal  equipment, 
whose  condition  (availability  on  the  aircraft)  also  can  change  the  use  characteristics  of  an  aircraft,  for 
example  a  gun  or  a  generator.  With  Configuration  Management  users  control  aircraft  usage  by 
configiration,  aircraft  changes  of  configuration  thru  reconfiguration,  and  aircraft  selection  based  upon 
estimated  times  to  prepare  the  aircraft  for  missions.  Configuration  control,  however,  is  a  users  option 
and  requires  additional  input  data  on  Form  17  and  preparation  of  Form  21.  Instructions  for  filling  out 
these  forms  are  included  in  Chapter  VIII. 

A  pseudo  configuration  control  containing  one  configuration  of  aircraft  and  using  a  default  search 
pattern  is  in  operation  when  the  configiration  data  is  omitted,  or  old  d3ta  packages  are  used.  The 
Main  Module  maintains  only  one  configuration  of  aircraft  but  still  subdivides  it  into  three  major 
statuses  described  below,  i.e.,  (1)  Available,  (2)  Cocked,  or  (3)  In-use  aircraft. 

b.  Aircraft  Statuses  -  Effect  on  aircraft  assignments. 

Aircraft  are  maintained  by  external  configuration  in  one  of  three  states:  (i)  available,  (2)  cocked 
(ready  to  go),  and  (3)  in  use.  An  aircraft  is  considered  available  if  it  is  ready  for  assignment  but 
requires  the  processing  of  the  pre-sortie  tasks  before  a  sortie  can  be  accomplished.  A  cocked  aircraft 
is  one  that  could  fly  immediately  on  some  missions,  that  is,  it's  fully  configured  and  requires  no 
processing  of  pre-sortie  tasks.  However,  a  cocked  aircraft  assigned  to  a  mission  that  requires  tlie 
aircraft's  reconfiguration  will  be  treated  as  an  available  aircraft  for  the  purpose  of  pre-sortie  tast< 
processing.  An  in-use  aircraft  is  just  that,  it  is  processing  some  piece  of  network  or  is  on  the  sortie 
task.  Available  and  cocked  aircraft  are  both  capable  of  being  assigned  to  mission  requirements;  in-use 
aircraft  are  obviously  not  usable  for  assignment. 

Aircraft  get  into  the  available  and  conked  states  in  the  following  manner.  When  an  aircraft  completes 
its  flight  and  all  its  maintenance  (reaches  end  of  network),  an  attempt  is  made  to  immediately  reassign 
it  to  any  mission.  If  it  is  not  needed,  it  is  placed  in  the  post-sortie  external  configuration  (defined  on 
Form  17)  as  an  available  aircraft.  When  an  aircraft  is  prepared  to  fly  but  does  not,  an  attempt  is  made 
to  reassign  it  to  a  mission.  If  the  aircraft  is  not  needed  in  either  a  cocked  or  non-cocked  condition, 
then  it  is  placed  in  the  pre- sortie  external  configuration  (defined  on  Form  17)  as  a  cocked  aircraft.  An 
aircraft  might  not  fly,  if  the  mission  it  was  assigned  to  had  been  flown  without  it  or  was  cancelled,  or 
if  the  aircraft  had  been  originally  designated  a  spare  and  was  not  destined  to  fly.  See  also  Chapter 
-V-III,  para  3-3. 

c.  Aircraft  Search  Patterns 

( 1 )  Acceptable/Non-Acceptable  Configuration 

A  search  pattern  is  a  sequential  list  of  acceptable  aircraft  configurations  and  statuses  that  can  be 
considered  in  the  mission  assignment  process.  This  list  is  ranked  in  order  of  configiration  and  status 
acceptability  for  assignment,  where  the  first  one  listed  is  the  most  acceptable  and  the  last  one  the 
least  acceptable.  By  simply  omitting  a  configm  ation  from  a  search  pattern,  it  automatically  becomes 
unacreptable  for  missions  using  that  search  pattern.  Search  patterns  are  defined  on  Form  21.  Each 
aircraft  mission  or  activity  defined  on  Form  17  can  specify  which  search  pattern  to  use  to  assign 
aircraft  for  any  requirement  for  that  mission  or  activity. 
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(2)  Reconfiguration  Requirements  and  Networks 

Reconfiguration  is  that  action  which  takes  an  aircraft  of  one  configuration  or  an  unconfigured  state 
and  converts  it  to  another  configuration.  Special  networks  are  defined  by  the  user  for  this  purpose.  In 
the  case  of  external  configurations,  those  networks  might  contain  taste  which  download  one  type  of 
ordnance  and  upload  another  or  the  uploading  of  one  type  of  ordnance  on  a  dean  or  externally 
unconfigured  aircraft. 

Generally,  the  first  configuration  in  the  search  pattern  spedfied  by  a  mission  contains  the 
configiration  requiring  the  least  effort  to  convert  the  aircraft  from  (reconfigure)  to  the  configuration 
which  the  mission  required  (defined  as  the  Pre-Sortie  External  Configuration  on  Form  17).  Normally, 
the  most  acceptable  status  would  be  first  a  cocked  then  an  available  aircraft  of  that  configuration. 
However,  this  is  entirely  under  user  control  through  his  establishment  of  the  search  patterns  on  Form 
21. 

When  a  configuration  other  than  what  is  needed  for  the  mission  is  used,  it  must  be  first  changed  to  the 
required  configuration,  i.e.,  reconfigured.  This  is  accomplished  through  the  use  of  the  reconfigiration 
networks. 

(3)  Simplified  Aircraft  Assignment  Search  Pattern  Example 

Assume  the  user  established  the  search  pattern  for  a  mission  in  the  most  logical  order,  i.e.,  (1)  cocked 
in  the  required  configuration,  (2)  available  in  the  required  configiration,  (3  thru  N)  available  in  other 
configurations,  and  (N  thru  M)  cocked  in  the  other  configurations.  Upon  notification  of  a  mission 
request  (frag)  the  aircraft  are  selected  according  to  the  user  defined  (Form  21)  search  sequence.  First, 
if  there  is  an  aircraft  in  the  cocked  state  of  the  configuration  required  for  the  mission,  the  aircraft 
will  be  selected  for  the  mission  and  all  its  pre-sortie  taste  will  be  omitted.  If  no  aircraft  are  cocked, 
then  one  in  the  available  state  of  the  required  configuration  is  used,  and  the  aircraft  begins  its  pre¬ 
sortie  taste.  When  no  aircraft  are  available  in  the  required  configiration,  the  remaining  configurations 
may  be  searched.  This  time,  an  "available"  aircraft  is  selected  first,  configured  or  reconfigured  to  the 
required  configiration,  then  begins  its  pre-sortie  taste.  Finally,  if  there  are  no  available  aircraft  in 
the  remaining  configurations,  remaining  configurations  would  be  selected,  unconfigured  and 
reconfigured  to  the  required  configuration  and  then  begins  its  pre-sortie  task.  As  can  be  seen,  when 
using  this  most  logical  order,  less  time  is  lost  in  making  the  mission  by  using  aircraft  in  configurations 
and  statuses  at  the  top  of  the  search  pattern  order.  However,  the  user  can  define  any  order  to 
simulate  the  conditions  established  for  his  simulation  runs. 

(4)  Cut-off  Time  -  time  based  control  of  aircraft  assignment.  On  the  Form  21,  there  is 
a  cut-off  time  for  each  configuration  specified  in  the  sequential  list  of  acceptable  configurations.  This 
time  is  a  key  factor  in  controlling  the  use  of  the  associated  configuration.  Its  value  should  be  at  least 
as  great  as  the  average  time  to  process  the  pre-sortie  taste  plus  any  reconfiguration  networks 
specified. 

The  average  time  to  process  pre-sortie  taste  should  include  the  sum  of  the  mean  task  times  for:  (I)  ail 
required  taste  between  the  entry  point  and  the  sortie  task  that  together  form  the  minimum  time-line 
for  the  pre-sortie  portion  of  the  network,  and  (2)  any  portions  (or  none)  of  the  remaining  pre-sortie 
taste,  such  as,  3  selection  mode  taste  or  taste  with  some  probability  of  not  being  accomplished. 

The  simulation  software  compares  the  cut-off  time  value  to  the  remaining  time  till  mission 
cancellation  and  when  insufficient  time  remains,  an  aircraft  in  the  associated  configuration  is  skipped. 
This  feature  permits  the  user  to  specify  configurations  earlier  in  the  search  pattern  that  are  more 
preferable,  but  take  longer  to  prepare  than  those  configurations  further  down  in  the  search  pattern. 
Conversely,  it  permits  placing  more  acceptable  configurations,  with  respect  to  preparation  time, 
further  down  in  the  search  pattern  list  in  order  to  maintain  more  of  them  for  some  other  mission  or 
activity. 


Cut-off  times  are  important  and  provide  significant  user  control  over  the  aircraft  selection  process. 


d.  External/Internal  Configurations 


Up  to  this  point,  the  word  configuration  has  been  used  in  a  very  generalized  manner  and  most  often 
referred  to  in  examples  in  terms  of  ordnance  or  external  configurations.  A  more  detailed  explanation 
of  the  external  configuration,  internal  configuration,  and  reconfiguration  networks  applicable  to  each 
will  be  described  within  the  summary  and  example  description  that  follows:  the  configuration 
management  feature  permits  the  use  of  either  external  configurations  only,  internal  configurations 
only  (with  a  single  or  dummy  configuration),  or  a  combination  of  them  both.  Form  ?  1  works  with  Form 
17  to  utilize  the  external  configuration,  while  internal  configurations  require  additional  data  on  Form 
21  and  completion  of  Form  22  and  23  described  later. 

( 1)  External  Configuration 

External  configuration  can  be  used  to  represent  weapons  loads  and  other  mission  related  configuration 
attributes.  Each  aircraft,  by  tail  number  is  carried  in  one  external  configuration  class  at  any  given 
time.  The  external  configuration  class  for  all  aircraft  of  a  particular  type  at  the  start  of  simulation 
will  be  either  the  first  configuration  specified  on  Form  17  for  that  aircraft  type  or  as  specified  on  a 
"STORAC"  change  card.  The  pre- sortie  external  configuration  class  specified  on  Form  17  is  assigned 
to  each  aircraft  that  starts  processing  pre-sortie  networks  for  a  specific  mission  name.  It  changes  to 
the  post-sortie  external  configuration  specified  on  Form  17  upon  completing  the  sortie  and  maintains 
that  configuration  throughout  all  post-sortie  processing.  Form  17  also  identifies  tlie  aircraft 
assignment  search  pattern  that  specifies  the  sequential  order  in  which  aircraft  classes  are  to  be 
searched,  obtained,  and/or  reconfigured  to  meet  the  mission  requirements. 

These  search  patterns  are  defined  on  Form  21.  For  each  mission  name,  it  lists  iri  order  of  preference 
the  desired  external  class  name,  cocked  cr  available  status,  reconfiguration  network  entry  node  (if 
reconfiguration  required),  and  cut-off  time  in  hO'irs  to  cancellation.  If  whenever  tiie  remaining  time  to 
cancellation  is  less  than  the  specified  cut-off  for  a  listed  configuration,  that  conf igiration  will  be 
skipped  in  the  search  for  aircraft  to  asrign  to  the  mission.  If  the  minimum  aircraft  have  already  been 
assigned  and  are  ready  to  fiy,  the  cut-off  time  test  uses  the  scheduled  take-off  time  instead  of  cancel 
time.  If  the  cut-offs  are  properly  based  on  task  times  for  reconfiguration  and  pre-sortie  processing, 
this  feature  will  prevent  aircraft  from  being  prepared  for  missions  they  cannot  make.  Space  is 
provided  for  two  configuration  choices  on  each  line  of  the  Form  21.  Continuation  cards  ("C"  in  Col  11) 
can  be  used  for  additional  configuration  choices  for  the  same  mission  name.  The  order  of  search  tor  a 
given  mission  name  is  first  line  left  entry,  first  line  right  entry,  second  (continuation)  line  left  entry, 
second  line  right  entry,  third  (continuation)  line  left  entry,  etc. 

Cocked  aircraft  are  aircraft  that  completed  pre-sortie  processing  for  a  mission  (as  (rime  or  spare)  but 
did  not  fly.  They  carry  the  pre-sortie  external  configuration  class  of  the  mission  they  missed.  If  a 
Form  21  calls  for  a  cocked  aircraft  and  blank  record iguration  nodes,  the  aircraft  will  go  directly  to  the 
sortie  task,  by  passing  through  all  pre-sortie  processing  in  zero  time.  TliiS  can  be  unrealistic  in  some 
situations  where  pre-sortie  launch  networks  should  be  processed  bv  cocked  aircraft.  To  correct  this,  it 
is  suggested  that  external  configuration  be  used  to  identify  loads,  that  loading  tasks  be  placed  in 
reconfiguration  networks,  and  that  pre-sortie  networks  only  include  launch  tasks  (waikaround,  engine 
start,  etc).  If  a  non-blank  dummy  node  name  is  placed  in  tire  external  reconfiguration  field  when  no 
reconfiguration  is  required,  properly  loaded  cocked  aircraft  will  proceed  through  the  pre-sortie  launch 
network  in  the  same  manner  as  available  aircraft. 

Aircraft  are  searched  and  selected  for  missions  exactly  in  tlie  order  listed  on  Form  21,  except  that  a 
listed  choice  will  be  skipped  when  time  remaining  to  cancel  or  scheduled  take-off,  whichever  is 
appropriate,  is  less  than  the  specified  cut-off.  11  a  particular  configuration  and  cocked/available 
status  is  not  listed  for  a  specific  mission  name,  it  will  never  be  considered  for  that  mission.  The  user 
miBt  take  care  to  assure  that  all  possible  configurations  that  could  occir  in  the  course  of  simulation 
have  some  disposition  on  Form  21. 


(2)  Internal  Configuration 

For  each  internal  configuration,  a  list  or  group  of  internal  equipment  required  to  be  operative  are  j 
specified  on  Form  23.  Generally,  only  equipment  on  which  maintenance  will  be  deferred  for  some 
mission  types  need  be  considered.  Equipment  names  and  quantities  required  are  listed.  An  aircraft 
may  have  four  generators,  but  may  be  able  to  fly  a  given  mission  if  at  least  two  are  operative.  These 
groups  of  required  equipment  are  referenced  on  Form  21.  Alternate  choices  should  be  listed  on  Form 
21  identifying  selection  order  of  airaraft  internal  configirations  to  be  prepared  and  the  internal 
reconfiguration  entry  nodes  of  the  repair  networks.  The  same  Form  23  groups  of  equipment  may  be 
referenced  by  several  different  mission  entries  on  Form  21  for  the  same  aircraft  type. 

The  internal  configuration  triggers  are  specified  in  the  networks  as  "T"  selection  nodes.  Only  selection  ! 
mode  D  can  be  used  from  the  same  node  as  a  "T"  but  when  used  in  this  manner,  the  user  should  be  sire 
of  what  is  being  done.  Also,  be  sure  the  "T"  branch  occurs  first  in  the  Form  ll's  before  its  parallel  : 
branches.  The  effect  of  each  "T"  selection  mode,  trigger  node  is  specified  on  Form  22.  A  trigger  node 
will  either  add  or  subtract  a  quantity  of  one  of  the  specified  equipment  from  the  internal  configuration 
status  of  the  aircraft  processing  through  the  "T"  node.  The  initial  authorized  quantity  of  each  item  on 
every  aircraft  at  the  start  of  simulation  is  also  given  on  the  Form  22  when  defining  the  trigger  node. 

"T"  nodes  that  subtract  can  be  placed  following  failure  docks  in  lieu  of  repair  networks  on  deferrable 
equipment.  "T"  nodes  that  add  can  be  used  in  internal  reconfiguration  networks  that  repair  equipment 
needed  for  a  given  mission. 

e.  Example  Configuration  Management  Problem 

Use  of  the  configuration  management  feature  is  illustrated  by  the  following  example  problem.  Three 
missions  are  used  in  the  A-99  scenario  and  the  main  networks  are  illustrated  in  Figure  4-8. 


MISSION  NETWORK 

I.D.  ENTRY  NODE 


PRE-SORTIE 
PROCESSING  TIME 

OF  UNCOCKED  A/C  DESCRIPTION 


FERRY  MN100  1.67 

RECON  MN200  1.83 

INTRD  MN300  1.92 


Transporting  aircraft 
Surveillance 
Offensive  penetration 


Both  external  and  internal  reconfiguration  is  performed  in  the  scenario  and  is  described  as  follows: 


EXTERNAL 
RECONFIGURATION 
ENTRY  NODE 


MEAN 

PROCESSING 

NETWORK  DESCRIPTION  TIME  (HRS) 


ERC100 

ERC200 

ERC300 

ERC400 

ERC500 

ERC600 


Download  racks 

.5 

Upload  pod 

.5 

Upload  racks  and  pod 

1.0 

Upload  bombs 

.75 

Download  pod  and  upload  bombs 

1.25 

Upload  racks  and  bombs 

1.25 

INTERNAL 
RECONFIGURATION 
_ ENTRY  NODE 


MEAN 

PROCESSING 

NETWORK  DESCRIPTION  TIME  (HRS) 


IRC  100 
IRC  200 
IRC300 
IRC400 


Mount  1  camera  .75 

Mount  2  cameras  1.5 

Mount  1  gun  1.0 

Mount  1  camera  and  lgun  1.75 
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The  internal  reconfiguration  network  necessary  to  mount  1  camera  and  1  gun  is  shown  in  Figure  4-9. 
Note  the  trigger  nodes  that  are  used.  The  networks  needed  for  the  other  internal  reconfiguration 
actions  are  similar  to  the  one  defined  in  Figure  4-9,  and  are  therefore  not  shown.  Networks  for  the 
external  reconfiguration  are  also  not  shown. 

The  Forms  illustrated  in  Figure  4-10  describe  all  the  information  needed  for  internal  and  external 
reconfiguration  in  the  A-99  scenario.  These  are  forms  17,  21,  22  and  23.  Recall  that  Form  17  permits 
the  definition  of  the  mission,  its  parameters,  and  the  aircraft  search  pattern  it  will  use  to  obtain 
aircraft  for  the  mission.  Form  21  is  where  the  sequence  of  aircraft  search  is  specified  by  both 
external  and  internal  configuration.  Note  that  the  user  can  now  differentiate  by  aircraft  status 
(cocked  or  available)  within  the  configiration  in  terms  of  order  of  search.  Form  22  and  23  are  used 
strictly  for  internal  configuration  parameters. 

In  Figure  4-10  there  are  three  missions  specified  on  Form  17,  each  using  a  different  search  pattern  for 
configiration  management.  The  Pre-Sortie  External  Configiration  for  each  mission  is  described  as  the 
configuration  the  A-99  aircraft  should  be  in  before  flying  the  sortie.  This  configuration  is  the  first  one 
searched  for  (cocked  then  available)  in  each  of  the  search  patterns  specified  on  Form  21.  Also,  not  all 
the  enternal  configurations  concerned  with  the  total  scenario  are  searched  within  each  search  pattern. 
Only  the  config'rations  which  the  user  determines  to  be  important  for  the  particular  missions  should 
be  searched.  These  restrictions  are  incorporated  in  SP1  due  to  the  relatively  low  priority  of  this 
mission. 

The  cut-off  time  specified  on  Form  21  is  obtained  by  adding  the  pre-sortie  processing  to  the  mean 
processing  time  for  reconfiguration  and  multiplying  it  by  1.1.  The  multiplication  is  performed  to 
provide  additional  processing  time  to  increase  the  probability  of  accomplishing  ali  pre-sortie  tasks 
(including  reconfigurations) 

At  the  start  of  simulation,  all  A-99  aircraft  are  internally  equipped  with  2  cameras  and  1  gun  as 
specified  on  Form  22.  The  RECON  mission  calls  for  2  cameras  to  be  on  the  airaraft.  In  search  pattern 
SP2,  a  search  is  initially  made  for  aircraft  configured  with  2  cameras  (GPl),andif  located,  are  not  to 
be  recomigured.  If  enough  aircraft  cannot  be  located  with  2  cameras,  then  a  search  pattern  is  made 
for  aircraft  with  1  camera  (GP2)  then  a  search  is  performed  to  find  an  aircraft  with  no  cameras  (GP5). 
When  they  are  located,  they  are  internally  reconfigured  to  contain  2  cameras.  The  sequence  of  the 
searches  is  very  important  and  only  those  groups  or  combinations  of  internal  equipment  specified  on 
Form  23,  which  are  unique  need  to  be  included.  For  instance,  in  this  scenario  three  groups  are  needed 
for  SP2  and  four  groups  are  needed  for  SP3.  It  is  unnecessary  to  specify  a  group  which  checks  for  zero 
cameras  only  because  GP5  already  checks  for  that,  and  group  GP5  is  also  needed  in  SP3. 

The  quantity  which  is  specified  on  Form  23  is  the  least  quantity  which  needs  to  be  operative  on  the 
aircraft.  So,  in  the  case  of  group  GP3,  the  group  would  be  satisfied  if  1  gun  is  operative  arid  any 
number  of  cameras  are  operative.  However,  the  order  that  the  groups  of  internal  equipment  are 
checked  is  also  important.  In  search  pattern  SP3  group  GP4  is  checked  for  the  external  configiration 
BMS500.  If  GP4  is  not  on  the  aircraft,  a  search  is  performed  for  an  aircraft  with  the  same  external 
configuration  and  group  GP3.  In  this  case  it  is  known  that  if  GP4  is  not  satisfied,  then  the  aircraft 
that  are  seal  ched  do  not  have  a  gun  or  a  camera,  or  has  neither.  So  if  enough  aircraft  are  located  that 
satisfy  GP3,  then  the  aircraft  need  only  to  be  reconfigured  for  an  additional  camera. 

This  example  problem  does  not  illustrate  all  of  the  possible  configuration  management  situations  that 
can  occur,  but  from  what  is  implemented,  several  basic  conclusions  can  lx?  (fawn.  In  regards  to  the 
search  patterns  defined  on  Form  21,  the  external  configuration  which  should  be  searched  for  first, 
should  be  the  Pre-Sortie  External  Configiration  specified  on  Form  17  for  the  particular  search 
patterns.  The  list  of  external  configurations  for  each  search  pattern  need  not  include  every  possible 
configuration,  but  the  configirations  included  should  be  chosen  with  care.  The  Cut-Off  Time  specified 
for  each  configuration  snould  represent  as  accirately  as  possible  the  mean  processing  time  for 
reconfiguration  plus  the  pre-sortie  processing  time  for  uncocked,  i.e.  available  aircraft.  The  sequence 
and  order  of  the  internal  configuration  searches  will  determine  the  necessary  uniqu--  internal  groups  to 
specify.  Finally,  particular  care  should  be  observed  to  ensure  that  the  trigger  nodes  are  set  up 
properly  in  the  reconfiguration  networks  in  order  to  prevent  a  change  in  internal  equipment  auantity 
balances  that  causes  the  maximum  specified  on  Form  23  to  be  exceeded  or  causes  a  negative  value. 
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15.  Priority  System  -  Start,  Pre-empt,  Expedite,  Backorder,  and  Overtime 

The  priority  system  in  the  software  is  a  flexible  scheme  designed  to  provide  the  user  with  adequate 
external  controls  for  its  operation  and  to  ensire  that  the  simulation  processes  jobs  in  a  manner  similar 
to  the  real  world.  External  controls  are  input  on  Form  18.  Chapter  VUl  describes  this  input  in  detail. 

The  priority  system  structure  contains  3  broad  categories  of  priorities.  Within  these  categories,  there 
are  several  individual  levels  or  values  of  priorities.  These  values  represent  the  relative  priority,  where 
the  lowest  number  is  the  most  urgent  priority,  i.e.,  9  is  higher  priority  than  15. 

This  system  can  best  be  described  with  the  example  in  Figure  4-11.  This  example  uses  the  default 
system  values  assigned  by  the  Main  Module,  which  can  be  changed  by  the  user  on  Form  18. 


r 


29 

•  # 

•  • 

•  • 

21 

Individual 

20 

Priorities 

19 

Values 

•  . 

Priority  Category  3  (the  lowest  priority  group) 
Contains  10  Levels 


A 


Priority  Category  2  (the  middle  priority  group) 
Contains  10  Levels 

Priority  Category  1  (the  highest  priority  group) 
Contains  10  Levels 


FIGURE  4-11.  DEFAULT  PRIORITY  STRUCTURE 


All  tasks  are  initially  given  a  priority  equal  to  the  lowest  value  (highest  number)  within  the  assigned 
priority  category.  Hence,  if  a  task  is  assigned  to  category  2  on  Form  12  (column  13),  it  would,  when 


first  started,  be  given  a  priority  of  19.  However,  when  the  tasks  are  used  in  the  presortie  networks  and 
the  mission  has  not  been  cancelled  the  tasks  will  be  given  an  initial  priority  equal  to  the  mission 
priority  specified  on  Form  20  (column  65,  66). 

The  following  provides  a  brief  description  of  the  task,  starting,  expediting,  preempting,  and 
backordering  procedures. 

a.  Start  Procedure  -  The  task  starting  procedure  uses  the  task  priority  as  the  main  selection 

factoi  (most  urgent  first)  and  where  priorities  are  equal,  the  task  diration  time  as  the  second  selection 
factor  (shortest  first).  See  also  LCNT  change  card  description.  I 

b.  Expedite  Procedure  -  Defined  for  each  priority  category  is  a  priority  waiting  factor, 
PWAIT,  which  equals  the  amount  of  time  a  task  within  that  category  will  wait  to  obtain  resources  prior 
to  applying  pre-emption.  Individual  task  priorities  are  used  only  to  determine  which  category  they  are 
currently  within  and  its  PWAIT  factor  is  used.  Also  a  general  factor  EXPED  is  defined. 

When  a  task  requires  a  resource  that  is  not  available,  the  following  actions  take  place: 
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(1)  Lower  priority  in-process  tasks  are  evaluated  as  to  whether  they  can  be  completed 
within  the  allowable  waiting  PWA1T,  of  the  higher  priority  task.  If  so,  the  higher  priority  task  will 
wait. 

(2)  If  not,  application  of  the  expedite  factor  (EXPED  multiplied  by  the  remaining  time) 
is  tested  with  the  same  question.  If  time  is  now  within  the  allowable  wait  time,  PWAIT,  the  task  will 
wait  and  the  expedite  factor  is  actually  applied  to  the  remaining  time  of  the  in-process  task  that  will 
be  releasing  the  resources 

(3)  If  allowable  wait  time,  PWAIT,  is  still  exceeded  and  no  lower  priority,  in-process 
task  can  provide  the  resources  by  this  procedire,  the  model  will  then  attempt  to  pre-empt  a  sufficient 
number  of  lower  priority  tasks  to  provide  the  resources. 

These  factors  (EXPED  and  PWAIT),  can  be  input  on  Form  18,  record  type  8  and  5  respectively  or  on 
change  cards  of  the  same  names  as  the  factors  themselves,  the  current  defaults  are  shown  on  Form  18. 
A  value  of  1.0  for  EXPED  would  effectively  negate  expedite  but  would  not  interfere  with  the  feature 
logic  which  prevents  unnecessary  pre-emptions. 

c.  Pre-empt  Procedure  -  The  Main  Module  uses  a  feature  called  "Pre-empt"  to  obtain 
resources  from  one  or  more  tasks  in  process  in  order  to  start  another  task  of  higher  priority.  It  does 
this  by  stopping  a  sufficient  number  of  lower  priority  tasks  that  are  in  process  and  backordering  them, 
thus  releasing  their  in  use  resources.  The  allowable  number  of  tasks  that  can  be  pre-empted  to  start 
any  other  single  task  is  limited  by  the  priority  category  in  which  the  task  attempting  to  start  belongs. 
The  limit,  NPRE,  can  be  input  on  Form  18  record  type  4  or  the  NPRE  change  card. 

The  Main  Module  determines  the  number  of  times  a  task  has  been  pre-empted.  If  it  is  the  first  or 
second  time,  it  is  considered  to  be  a  true  pre-empt  and  a  time  additive  is  applied  to  the  remaining 
time.  However,  if  it  is  the  third  or  subsequent  time  the  pre-emption  occurred,  no  additive  is  applied  to 
the  task  time,  i.e.,  the  task  is  considered  as  backlog  (fill  in,  low  priority)  work.  This  additive  simulates 
a  pre-empting  cost  such  as  a  reset-up  time,  transportation  time,  or  any  general  pre-empt  lost  time. 
The  additive  is  a  formula  which  effectively  extends  the  remaining  task  time  by  multiplying  it  by  the 
value  PCT.  A  PCT  value  of  1.2  causes  a  20%  increase  in  the  remaining  time.  Input  of  this  percent  can 
be  accomplished  on  Form  18,  subtype  9  record,  or  thru  the  PCT  change  card.  The  default  PCT  value  of 
1.0  effectively  negates  this  additive.  By  using  this  pre-empt  methodology,  the  simulation  process 
ensiles  resource  utilization  while  any  backlog  exists,  but  more  importantly,  ensures  the  completion  of 
low  priority  work  while  maintaining  overall  availability  of  the  resources  for  more  important  work. 

The  shift  mechanism  uses  the  overtime  and  pre-empt  features  whenever  a  shift  change  occurs  that 
lowers  authorizations  and  enough  authorizations  cannot  be  obtained  from  the  onhand  balance.  The 
shift  mechanism  first  checks  to  see  if  any  jobs  in  process  could  finish  within  the  overtime  allowance 
for  their  category.  If  more  authorizations  are  still  needed,  the  shift  mechanism  checks  to  see  if  expe¬ 
diting  jobs  would  allow  them  to  finish.  If  number  needed  still  not  satisfied,  it  pre-empts  jobs  to  get  the 
remainder  of  the  needed  authorizations. 

d.  Backorder  Procedure 

If  a  task  is  placed  into  backorder,  either  because  it  could  not  start  due  to  insufficient  resources  or  it 
was  pre-empted  by  a  higher  priority  task,  then  the  task's  priority  is  escalated  in  proportion  to  the 
amount  of  time  it  is  backordered.  For  every  unit  of  time  in  backorder  equal  to  a  delta  value,  the  task 
priority  is  increased  by  one  (made  numerically  one  less).  Tasks  can  crossover  from  one  category  to 
another.  This  delta  time  is  input  on  Form  18  record  type  7  or  with  the  DELT  change  card. 

16.  Cannibalization  and  the  Network  I  Selection  Mode 
a.  General  Description 

The  purpose  of  the  cannibalization  feature  is  to  obtain  aircraft  for  a  mission  at  frag  time  through  a 
cannibalization  action,  when  the  on-hand  balance  of  the  aircraft  is  less  than  the  minimum  required. 
Several  items  work  together  to  control  the  use  of  this  feature. 
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The  SWICH  (CIO  change  card  is  used  to  enable  the  feature  ($WICH(10M,on)  or  disable  it 
(SWICH(IO)aO,off).  The  user  must  set  SWICH  #10  on  or  cannibalization  will  not  take  place  since  the 
SWICH  #10  default  is  off. 

Cannibalization  cannot  take  place  unless  the  I  selection  mode  task  is  used.  The  I  mode  specifies  those 
tasks  containing  part  consumptions  that  can  take  advantage  of  cannibalization. 

The  I  (ignore)  mode  also  indicates  that  the  time  specified  is  a  cannibalization  removal  time.  During 
normal  processing  where  the  part  is  obtained  from  supply  (on-hand  quantity  is  greater  than  zero)  the 
time  is  to  be  ignored.  However,  if  the  part  is  unavailable  from  supply,  the  task  would  be  backordered 
and  the  aircraft  would  probably  be  NORS.  For  any  subsequent  satisfying  of  this  part  demand  by  a 
cannibalization  action,  the  time  and  manpower  resources  specified  on  the  I  mode  task  would  be  used  as 
the  removal  time  and  resource. 

When  activated,  cannibalization  reviews  all  in-use  aircraft  to  qualify  them  as  candidate  donors  or 
candidate  acceptors.  Only  NORS  aircraft  can  be  considered  as  either  donors  or  acceptors.  Given  that 
the  donors  and  acceptors  are  qualified,  the  Main  Module  then  determines  if  the  manpower  resources  on 
the  I  mode  task  are  available.  If  so,  and  donors  and  acceptors  are  matched  up,  the  Main  Module)  (1) 
simulates  the  removal  of  the  part  from  the  donor,  (2)  dedicates  the  part  to  the  acceptor,  (5)  delays  the 
processing  of  the  acceptor  part  demand  task  until  the  part  Is  available,  and  (4)  establishs  a  like  demand 
for  the  part  on  the  donor  aircraft  (A  copy  of  the  acceptor  network  from  the  I  mode  task  to  the  end  of 
network  is  filed  against  the  donor  AC). 

Other  external  controls  are  available  to  the  i»er.  The  maximum  number  of  part  demands  that  can  be 
satisfied  by  cannibalization  to  obtain  on  aircraft  has  a  default  value  of  two  (2).  Also  the  maximum 
number  of  holes  on  (parts  obtained  from)  a  donor  aircraft  that  can  be  made  through  cannibalization  lias 
a  default  of  five  (5).  The  CANNIB  change  card  allows  user  input  of  these  quantities,  by  aircraft  type. 

The  user  may,  In  his  network,  control  where  he  wants  a  part  consumption  task  considered  for  cannibali¬ 
zation  action  bv  use  of  the  I  selection  mode  os  previously  described.  However,  using  the  same  task 
elsewhere  In  the  network  without  the  I  selection  mode  or  any  other  part  demand  task  without  the  I 
mode,  no  cannibalization  will  be  considered  lor  the  tasks  In  these  instances. 

There  can  be  only  one  of  a  particular  part  cannibalized  at  a  time  for  a  particular  aircraft.  If  more 
than  one  demand  for  a  part  Is  backordered,  all  demands  except  the  last  must  be  satisfied  before  canni¬ 
balization  could  be  used. 

b.  Rules 

To  recap.  The  rules  generating  the  use  of  cannibalization  are: 

(1)  SWICH  #10  must  be  set  to  one  (I). 

(2)  1  selection  mode  mist  be  used  on  tasks  with  a  part  consumption  to  be  considered  for 
cannibalization. 

( ))  Only  a  single  part  consumption  and  men  resources  are  permitted  on  on  I  mode  task. 

(4)  If  the  I  mode  is  used,  the  task  time  Is  always  Ignored  except  diring  cannibalization. 

(5)  If  the  1  mode  is  used  on  a  task  without  a  consume  on  it,  the  Input  module  assumes 
the  mode  Is  D  (DO),  makes  the  substitution,  gives  a  message,  and  continues. 

(6)  The  CANNIB  change  card  can  reaet  the  maximum  no  of  parts  to  cannibalize  for,  and 
maximum  no.  of  holes  permitted  on  an  aircraft  caused  through  cannibalization. 

(7)  Acceptor  Aircraft  -  Aircraft  which  satisfy  the  following  conditions  ore  set  up  as 
candidate  acceptor  aircraft! 


(a)  No  scheduled  or  unscheduled  jobs  are  in  process. 

(b)  At  least  one  part  is  backordered. 

(c)  Only  parts  are  backordered. 

(d)  Aircraft  in  post  sortie  or  activity  processing. 

(e)  Tasks  backordered  and  eligible  for  receiving  a  cannibalized  part  must  be  the 
only  jobs  backordered  for  the  aircraft. 

(f)  The  number  of  tasks  backordered  and  eligible  for  receiving  a  cannibalized  part 
must  be  less  than  or  equal  to  a  limit  determined  by  the  user. 

(g)  The  aircraft  cannot  be  waiting  for  dedicated  parts  from  a  previous 
cannibalization  action  (be  a  cirrent  acceptor). 

(h)  The  aircraft  cannot  have  an  in-process  donation  to  another  aircraft  (be  a 

current  donor). 

(9)  Donor  Aircraft  -  Aircraft  which  satisfy  the  following  conditions  are  set  up  as 
candidate  donor  aircraft: 

(a)  No  scheduled  or  unscheduled  jobs  are  in  process. 

(b)  At  least  one  part  backordered. 

(c)  Only  parts  are  backordered. 

(d)  Number  of  jobs  backordered  plus  in-process  removals  must  be  less  than  the 
maximum  no  of  holes  (limit)  permitted  on  the  aircraft. 

(e)  Cannot  be  waiting  for  dedicated  parts  from  a  previous  cannibalization  action 
(be  a  current  acceptor). 

(f)  Must  be  post-sortie  or  activity  processing  or  an  aircraft  pre-sortie  processing 
whose  mission  has  flown  or  canceled. 

17.  Performance  Summary  Report  (PSR)  Partitioning  -  See  Main  Module  PSR  report  description. 

a.  General  Description 

This  feature  permits  the  user  to  select  which  Performance  Summary  Report  (PSR)  statistics  lie  wants 
printed.  It  affects  only  the  Level  1  PSR  and  is  activated  by  a  change  card,  PSROUT.  If  no  PSROUT 
cards  are  input,  printing  of  the  Level  1  PSR  is  done  exactly  as  it  always  has  been. 

Level  2  reports  are  unaffected  by  this  feature  and  will  print  in  full.  Also,  the  outputs  to  the  GRAPH 
program  are  not  changed  in  any  way.  Finally,  there  is  no  affect  on  the  warmup  period.  The  capability 
changes  only  the  printing  of  the  Level  1  statistics.  Calculations  are  still  accomplished  as  if  the 
statistics  were  to  be  printed. 

b.  Feature  Activation/Use 

Change  card  PSROUT  is  used  and  specifies  in  the  FPAR  field  a  point  in  time  when  the  special  print 
request  is  to  be  activated.  (See  Change  Card  write-up  for  format.)  Immediately  following  this  change 
card  is  a  request  card  specifying  the  statistics  or  group  of  statistics  to  be  printed. 

The  format  of  this  request  card  is  free  form,  in  that,  the  entries  (statistic  numbers)  may  be  placed  in 


any  column,  between  Col  1-72.  Entries  must  be  separated  by  at  least  one  blank  space  or  a  comma  and 
an  asterisk  (*)  preceded  by  a  blank  must  follow  the  last  entry.  The  asterisk  at  the  end  of  the  set  of 
requested  statistics  permits  the  use  of  more  than  one  request  card.  This  asterisk  must  only  be  on  the 
last  request  card  entered. 

Entire  groups  of  statistics  (such  as  AIRCRAFT)  can  be  specified  if  ail  statistics  in  that  group  are 
needed.  A  particular  group  is  specified  by  appending  the  letter  G  to  the  group  number,  e.g.,  G2,  with 
no  intervening  space  between  the  G  and  the  2.  Group  numbers  have  been  assigned  sequentially  to  the 
sections  of  statistics  as  printed  in  the  PSR  with  the  OPERATIONS  Section  as  Gl,  AIRCRAFT-G2, 
PERSONNEL-G3,  SHOP  REPAIR-G4,  SUPPLY-G5,  and  EQUIPMENT-G6.  Both  groups  and  specific 
statistics  numbers  can  be  intermixed  in  any  sequence. 

Statistic  numbers  are  not  those  seen  on  the  PSR  print-out  but  are  sequentially  assigned  and  will  be  the 
same  as  the  sequence  numbers  printed  on  the  Decoder  run  output  using  the  SPEC  option  GRPD=nn. 

An  example  of  a  request  for  3,  6,  23,  24,  49  and  all  of  Group  3  to  be  printed  from  the  30th  day  on 
would  be: 


PSROUT  30.0 

3, 6, G3, 23,24, 49  * 

Any  PSROUT  request  remains  in  effect  until  another  PSROUT  change  card  request  is  encountered  in 
simulation  time. 

PSROUT  requests  are  not  additive.  Each  one  effectively  deletes  all  others  with  a  FPAR  time  less  than  t 
itself,  i.e.,  they  become  effective  at  the  time  specified.  Also,  it  is  safest  to  specify  a  time  a  little  ! 
previous  to  the  first  PSR  to  be  affected. 

One  additional  option  to  request  all  statistics  after  fewer  statistics  were  requested  during  a  simulation 
run,  is  accomplished  by  placing  ALL  *  on  the  request  card  (i.e.  card  following  the  PSROUT  change 
card). 


c.  Special  Consideration 

When  users  select  some  of  the  statistics  such  as  the  ones  specifying  %  of  time,  these  may  not  be  too 
meaningful  without  their  companion  statistics. 

18.  Initial  Class  Assignment  for  Aircraft 

The  Input  Module  defines  the  initial  class  into  which  all  aircraft  are  placed  at  the  beginning  of  the 
simulation.  This  initial  class  will  be  the  first  class  specified  for  the  aircraft  on  Form  17  in  the  Mission 
Class/ Configuration  field  (Col  22-27),  i.e.  the  first  Form  17  card  specifying  the  aircraft. 

The  change  card,  STORAC,  allows  the  user  to  redefine  this  initial  class,  thereby  causing  the  aircraft  to 
be  placed  into  a  different  class  than  that  predefined  by  the  Input  Module.  Class  numbers  can  be  found 
in  the  Class  Dictionary  printed  at  the  end  of  the  input  run  (when  input  module  spec  option  INFO=2  or  3 
is  selected). 

Only  aircraft  present  at  the  beginning  of  the  simulation  (time  =  0)  will  be  placed  in  this  class.  New 
aircraft  generated  during  simulation  will  follow  the  aircraft  generating  procedure. 

If  this  STORAC  change  card  is  not  input,  the  aircraft  will  be  assigned  the  predefined  class. 

The  user  cannot  specify  "available"  or  "cockecf'  within  the  class,  the  aircraft  will  automatically  be 
placed  in  the  "available"  status  of  the  initial  class. 

19.  Aircraft  Timing  Switch  -3,  K,  and  U  Selection  Mode 


This  aircraft  K  selection  mode  timing  switch,  the  KTIMSW  controls  the  processing  (or  not  processing) 


of  network  tasks  coded  with  a  3  or  K  selection  mode. 


The  primary  control  of  the  setting  and  resetting  of  this  switch  is  done  by  tasks  coded  with  a  K 
selection  mode.  A  secondary  control  for  resetting  the  switch  is  done  by  tasks  coded  with  a  U  selection 
mode.  The  switch  is  a  three  position  switch  (off=0,  partially  on=l,  fully  on=2). 

When  the  switch  is  off  or  partially  on,  both  3  and  K  selection  mode  tasks  are  processed.  When  fully  oh 
these  tasks  are  skipped.  The  partially  on  condition  permits  users  to  process  series  of  3  mode  tasks, 
even  with  intervening  tasks  using  other  selection  modes.  The  3  tasks  will  set  the  switch  to  partially 
on. 

K  tasks,  however,  will  set  the  switch  fully  on,  regardless  of  the  switch  condition,  and  trigger  rhe 
simulation  software  to  reset  the  switch  to  off  after  a  specified  time  interval.  This  triggering  of  the 
reset  is  done  at  the  beginning  of  the  K  task  prior  to  processing  it.  The  time  interval  is  by  aircraft  type 
and  defaults  to  24  hours.  However,  the  user  may  use  the  KTIMSW  change  card  to  input  a  new  time 
interval. 


If  the  user  fails  to  control  the  switch  with  a  K  mode  task,  the  simulation  software  will  take  some 
default  actions  at  End-of-Network.  End-of-Network  (EON)  is  defined  as  the  end  of  network 
processing,  that  is,  the  last  task  completion.  This  can  occur  at  either;  (1)  true  end-of-network,  (2)  at 
the  sortie  task  for  a  spare  aircraft,  or  (3)  at  the  sortie  task  for  an  aircraft  whose  mission  has  already 
occurred  or  been  canceled.  If  at  least  one  3  mode  task  was  processed  and  the  switch  was  partially  on 
when  reached,  the  switch  would  automatically  be  set  fully  on  and  the  software  triggered  to  reset  the 
switch  to  off  after  the  specified  time  interval.  With  the  switch  either  fully  on  or  off  at  EON,  no 
action  is  taken. 

The  U  selection  mode  is  effective  only  if  the  switch  is  fully  on  and  a  reset  of  it  has  been  triggered. 
The  U  selection  mode  will  unschedule  the  switch's  resetting  and  set  it  off  immediately  upon  being 
processed.  If  the  switch  is  off  or  partially  on  when  the  U  selection  mode  is  processed  no  action  is 
taken.  In  all  cases  the  task  coded  with  the  U  mode  will  be  processed  as  a  do  task. 


Table  4-5  contains  a  total  recap  of  all  K  time  switch  KTIMSW  actions  that  can  take  place. 


Processing 

Switch 

Value 

Directed 

Swi  tch 

Location 

Current 

Changed  to 

Action 

Reset 

At  J  Task 

0 

1 

Process  3  task 

N/A 

At  3  Task 

1 

1  NC 

Process  3  task 

N/A 

At  3  Task 

2 

2  NC 

Skip  3  task 

N/A 

At  K  Task 

0 

2 

Process  K  task 

Scheduled 

At  K  Task 

1 

2 

Process  K  task 

Scheduled 

At  K  Task 

2 

2  NC 

Skip  K  task 

N/A 

At  EON 

0 

0  NC 

N/A 

N/A 

At  EON 

1 

2 

N/A 

Scheduled 

At  EON 

2 

2  NC 

N/A 

N/A 

At  U  Task 

0 

0  NC 

Process  U  task 

N/A 

At  U  Task 

1 

1  NC 

Process  U  task 

N/A 

At  U  Task 

2 

0 

Process  U  task 

Unscheduled 

I 


Note;  NC  =  No  change 

N/A  =  Not  applicable 


The  KTIMSW  can  be  used  in  either  pre-  or  post-sortie  networks.  However,  there  is  only  one  (1) 
K  timing  switch  per  aircraft.  Once  the  K  mode  task  has  been  processed  ail  subsequent  3  or  K  mode 
tasks  in  the  network  will  not  be  processed  unless  the  reset  time  interval  has  passed  or  a  U  selection 
mode  task  has  been  processed.  Therefore,  use  of  the  feature  in  pre-sortie  networks  could  negate  post¬ 
sortie  use. 

RAM  aircraft  are  returned  to  the  simulation  with  the  switch  turned  off  and  no  switch  resetting  sche¬ 
duled.  New  aircraft  enter  the  simulation  in  the  same  way. 

20.  Warm-up  Period 

The  warm-up  period  is  the  period  of  time  from  the  beginning  of  a  simulation  (time  0.0)  until  a  user 
defined  integer  number  of  days  has  been  completed.  The  warm-up  period  is  used  to  approach  a  steady 
state  situation  before  statistical  evaluation  of  the  simulation  is  attempted.  For  example,  at  the 
beginning  of  the  simulation,  all  aircraft  are  in  the  "beginning"  configuration  and  there  are  no  parts 
backordered.  The  simulation  must  be  run  for  a  period  of  time  before  the  aircraft  are  dispersed  into 
other  configurations  or  assigned  to  network  processing,  and  the  parts  are  assigned  to  tasks  and/or 
backordered.  Once  a  reasonable  steady  state  condition  has  been  reached,  any  bias  which  could  have 
been  caused  by  the  start-up  of  the  simulation  has  been  eliminated. 

During  the  warm-up  period,  no  intermediate  Performance  Summary  Reports  (PSR's)  will  be  produced 
and  no  RAM  repair  or  attrition  will  occur.  The  RAM  repairs  and  attritions  will  not  occur  so  that  at  the 
end  of  the  warm-up  period,  the  simulation  will  have  the  correct  number  of  aircraft  to  begin  the 
statistically  supported  segment  of  the  simulation.  However,  statistics  will  be  accumulated  during  the 
warm-up  period.  At  the  end  of  the  warm-up  period,  a  level  2  PSR  is  produced  and  the  level  1  and  level 
2  totals  are  zeroed.  This  level  2  report  allows  the  user  to  collect  statistics  on  the  warm-up  period 
only.  It  is  normally  only  used  for  debug  purposes. 

The  WARMUP  change  card  is  used  to  define  the  length  of  the  warm-up  period.  When  this  change  card 
is  encountered,  the  first  PSR  is  scheduled  tor  the  end  of  the  warm-up  period.  This  first  PSR  will 
produce  a  level  2  report  which  encompasses  the  whole  warm-up  period  regardless  of  the  values  of 
change  card  RFREQ  and  RCYC.  Then  RFREQ  and  RCYC  have  the  end  of  the  warm-up  period  as  their 
reference  point.  For  example,  if  the  warm-up  period  is  for  12  days  and  RFREQ  is  defined  equal  to  5 
and  RCYC  is  defined  equal  to  2,  the  following  will  occur: 


0.0 

WARMUP 

12.0 

17.0 

22.0 

*> 

• 

Produce  level  2 
Report  for  all  of 
Warmup  Period 

PSR 

Level  1 
Report 

PSR  Level  1 
and  Level  2 
Report 

The  WARMUP  change  card  can  only  be  input  at  time  0.0.  The  warm-up  period  will  be  assumed  to  end 
at  time  0.0  if  no  WARMUP  change  card  is  used.  The  first  PSR  will  occur  at  the  end  of  the  warm-up 
period  unless  the  warm-up  period  is  of  0  length.  Data  being  sent  to  post- processors  (matrix,  parts, 
RFS,  etc.)  includes  the  warm-up  period  if  requested. 


21.  ATTRITION  -  See  RAM/ ATTRITION/AIR  ABORT  Relationship. 


This  option  allows  the  user  to  delete  or  remove  aircraft  from  the  simulation  based  on  an  attrition 
percentage.  To  activate  this  feature,  use  the  PRBATT  change  card  to  set  attrition  by  mission  type. 
The  attrition  percentage  is  the  percent  of  aircraft  which  will  be  removed  by  attrition  of  all  aircraft 
which  fly  and  do  not  air  abort.  Conditional  probabilities  must  be  considered  here  by  the  user.  See  the 
relational  write-up  concerning  RAM/ Attrition/ Air  Aborts.  If  no  attrition  percentage  is  defined  for  a 
mission  type,  it  is  assumed  to  be  0%.  If  a  percentage  is  input,  it  is  an  integer  value  between  1  and  100 
inclusive. 

Based  on  the  mission  type  and  the  attrition  percentage,  the  LCOM  II  will  internally  determine  when 
attrition  will  occur  and  remove  the  aircraft  from  the  simulation.  The  number  of  possessed  aircraft 
will  be  decremented  by  1  in  this  case.  The  PRBATT  change  card  can  only  be  input  at  time  0.0. 
Attrition  will  be  disabled  during  the  warm-up  period.  In  LCOM  II,  aircraft  are  removed  by  attrition 
after  the  sortie  task  and  therefore  all  flying  hours  will  be  accounted  for.  When  attrition  occurs,  the 
sortie  length  can  be  reduced  by  a  percentage  defined  on  the  ATTPCT  change  card. 

The  decrease  percentage  is  defined  by  aircraft  type.  The  decrease  percentage  must  be  an  integer 
number  between  1  and  100.  One  possible  user  requirement  that  currently  cannot  be  handled  by  the 
attrition  option  is  to  replenish  at  some  time  in  the  future.  This  can  be  handled  by  turning  off  the 
attrition  option  (0%),  creating  an  attrition  network  controlled  by  "E"  selection  modes,  consuming  the 
aircraft,  accomplishing  a  task  whose  length  equals  the  time  to  wait  before  replenishing  and  then 
generating  the  aircraft  again.  The  newly  generated  aircraft  will  be  placed  in  the  "standard" 
configuration.  However,  no  attrition  statistics  are  collected.  Use  the  hit  matrix  to  determine  the 
number  of  attritions. 

22.  RAM  Repair  -  See  RAM/ ATTRITION /AIR  ABORT  Relationship 

An  aircraft  which  returns  from  a  sortie  may,  because  of  extensive  damage,  be  repaired  by  a  special 
team  whose  personnel  are  not  part  of  the  local  manning.  This  is  called  Rapid  Area  Maintenance 
(RAM).  In  LCOM  II,  the  PRBRAM  change  card  will  be  used  to  define  the  probability  of  RAM  repair 
percentage  by  mission  type.  The  RAM  percentage  is  an  integer  value  between  l  and  100  inclusive. 
Also  required  is  a  RAM  repair  time  in  terms  of  a  mean  and  a  variance  value  defined  by  aircraft  type  on 
the  RAMTME  change  card. 

Should  these  change  cards  not  be  defined  for  certain  missions  and/or  aircraft  types,  the  percentage 
would  default  to  0  and/or  the  mean  time  in  days  and  variance  would  default  to  0  thus  essentially 
disabling  RAM. 

The  mean  time  in  days  and  the  variance  will  be  used  as  input  to  a  lognormal  distribution  calculation 
which  will  result  in  the  RAM  repair  time  to  be  used.  During  the  warm-up  period,  RAM  will 
automatically  be  disabled. 

If  RAM  is  required  for  an  aircraft,  the  aircraft  will  be  removed  from  the  simulation  at  the  end  ot  the 
sortie  task.  It  will  be  "reinstated"  into  the  simulation  at  the  end  of  the  calculated  RAM  repair  time. 
The  list  of  all  failed  clocks,  which  was  saved  at  the  beginning  of  RAM,  is  reattached  to  the  aircraft  at 
this  time.  The  aircraft  then  will  go  to  the  node  immediately  following  the  sortie  task  as  defined  by  the 
user.  At  this  point,  the  aircraft  is  considered  in  post-sortie  processing.  Aircraft  post-sortie 
turnaround  time  is  calculated  from  this  point  to  the  end  of  the  network.  The  RAM  repair  time  is  not 
included  in  the  turnaround  statistic. 

The  RAM  percentage  is  only  applied  against  those  aircraft  wliich  the  model  has  determined  actually  fly 
and  do  not  air  abort  or  disappear  through  attrition.  Read  the  RAM/ Attrition/Air  Abort  relationship 
described  later. 

Because  of  the  method  used  to  simulate  RAM  (temporarily  removing  and  then  regenerating  the 
aircraft),  there  can  never  be  any  resources  used  or  consumed  during  the  RAM  repair  period.  When  an 
aircraft  returns  from  RAM,  its  configuration  remains  the  same  as  the  configuration  it  was  in  when  it 
landed  after  the  sortie. 
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23.  AIR  ABORTS/SYMPATHETIC  ABORTS  -  See  RAM/ ATTRITION/AIR  ABORT  Relationship 

This  option  gives  the  user  the  capability  to  have  air  aborts  occur.  The  AABORT  change  card  is  used  to 
input  all  the  air  abort  data  specifications.  The  user  specifies  on  this  change  card  a  percent  factor  by 
mission  type  which  will  control  the  frequency  of  the  air  aborts.  An  air  abort  sortie  length  is  specified 
on  the  AABORT  change  card  as  a  decrease  percentage  where,  for  example,  a  value  of  50  would 
indicate  the  scheduled  sortie  length  is  to  be  decreased  by  50%.  This  decrease  percentage  is  specified 
by  mission  type  on  this  change  card. 

When  an  aircraft  is  air  aborted,  upon  landing  it  begins  processing  through  its  post-sortie  processing 
networks.  However,  the  configuration  of  the  aircraft  will  be  that  which  is  specified  on  the  AABORT 
change  card.  Also  the  user  may  want  special  processing  to  occur  immediately  after  the  sortie.  The 
next  node  after  the  sortie  can  be  altered  when  an  air  abort  or  sympathetic  air  abort  occurs  by 
specifying  the  control  table  index  on  the  AABORT  change  card.  This  value  is  obtained  fom  the  control 
table  printout  from  the  Input  Module  run.  This  index  is  specified  by  mission  type. 

Sympathetic  air  aborts  are  handled  exactly  the  same  as  air  aborts.  A  matrix  containing  the  number  of 
sympathetic  air  aborts  required,  based  on  the  number  of  aircraft  flying  for  the  mission  and  the  number 
of  aircraft  which  air  aborted,  is  used  to  determine  the  aircraft  which  will  sympathetic^  air  abort. 
This  matrix  is  "hardwired"  into  the  Main  Module  and  can  only  be  altered  by  recompiling.  The  matrix  is 
shown  in  figure  4-12.  Sympathetic  air  aborts  cannot  occur  for  missions  which  have  more  than  6 
aircraft  flying. 
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FIGURE  4-12.  AIR  ABORT  MATRIX 


24.  RAM/ ATTRITION /AIR  ABORT  RELATIONSHIP 

An  aircraft  cannot  have  more  than  one  of  these  three  conditions  occur  on  a  specific  mission.  The  Main 
Module  internally  determines,  using  the  user  input  percentages,  if  one  of  these  conditions  occurs.  The 
determination  is  made  just  prior  to  the  sortie. 

First,  a  determination  is  made  if  an  air  abort  will  occir.  If  so,  the  aircraft  is  flagged  to  have  the  air 
abort  occir  after  the  sortie  and  the  sortie  length  is  shortened.  Then  aircraft  which  will  sympatheticly 
abort  are  also  flagged.  Finally,  for  all  aircraft  which  will  fly  but  are  not  flagged  to  abort,  the  aircraft 
selected  for  RAM  and  attrition  are  flagged.  Those  selected  to  be  removed  by  attrition  are  flagged 
first  and  from  the  remaining  unflagged  flying  aircraft,  those  which  are  to  go  to  RAM  are  picked.  With 
this  scheme,  no  aircraft  can  have  more  than  one  of  the  above  conditions  occir  during  the  same 
mission. 
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Once  the  sortie  is  completed,  a  check  is  made  for  a  flag  attached  to  the  aircraft.  If  attrition  is  to 
occur,  the  aircraft  is  removed  from  the  simulation.  If  RAM  repair  is  required,  the  aircraft  is 
temporarily  removed  from  the  simulation.  Obviously  air  aborts  and  attrition  occur  during  a  sortie,  but 
for  simulation  pirposes  checking  for  these  occurrences  before  the  sortie  and  shortening  the  sortie 
length  as  appropriate  does  not  affect  the  simulation  results. 

The  attrition  statistic  in  the  main  Performance  Summary  Report  is  updated  just  prior  to  the  sortie 
when  the  flag  check  was  made.  It  cannot  be  updated  after  the  sortie  because  mission  information  is 
not  available.  The  number  of  RAM  repairs  and  air  aborts  are  also  updated  just  prior  to  the  sortie. 
Note  that  the  air  aborts  and  sympathetic  air  aborts  are  in  the  air  abort  total. 

25.  TASK  SUBSTITUTION 

If  the  user  needs  to  replace  one  task  with  another,  for  example,  for  thru-flight  and  post-flight  tasks, 
the  TSUB  and  TSUB1  change  cards  will  be  used  to  define  the  task  ID  of  the  task  which  will  be  replaced 
and  a  task  ID  of  the  task  which  will  be  substituted.  Also  defined  on  these  change  cards  is  the  time 
during  the  day  when  the  replacement  will  occur  and  when  the  tasks  which  were  replaced  are  reset  to 
their  original  task  ID.  Only  those  replaced  will  be  reset.  This  means  that  if  task  A  was  to  replace  task 
B,  and  task  B  was  specified  twice  in  the  networks,  and  task  A  was  specified  four  times  in  the  networks; 
then  the  two  B  tasks  would  be  replaced  with  A  tasks.  Also,  only  these  two  A  tasks  would  be  later  reset 
to  B  tasks  again.  The  original  four  A  tasks  would  not  be  reset  to  B  tasks. 

For  the  TSUB  change  card  the  reset  time  is  assumed  to  be  within  the  same  day  as  the  replacement 
time  and  also  later  in  the  day.  The  replacement  and  reset  times  are  input  as  decimal  hours  ( 1 1.0  is 
eleven  o'clock;  13.5  is  one  thirty).  Only  tasks  of  the  same  type  may  be  substituted  for  each  other,  and 
neither  a  sortie  task  nor  the  dummy  task  can  be  used.  No  sortie  tasks  can  be  substituted  and  the 
dummy  task  cannot  be  used  for  substitution.  This  substitution  takes  place  on  a  daily  basis  and  occurs 
throughout  simulation. 

For  the  TSUB1  change  card  the  replacement  time  and  reset  time  is  specified  in  decimal  days, 
indicating  the  particular  days  task  substitutions  are  to  take  place.  There  is  no  cycling  of  the 
substitutions,  one  TSUB1  card  specifies  one  replacement  and  one  reset.  If  the  reset  field  on  the  TSUB1 
card  is  blank  or  zero  then  no  reset  will  occur. 

26.  FCF  Task  Collection 

A  Functional  Check  Flight  (FCF)  task  can  be  defined  using  the  FCFTSK  change  card.  This  permits  a 
collection  of  the  number  of  times  the  FCF  task  is  processed;  this  number  is  printed  in  the  main 
Performance  Summary  Report.  If  a  FCF  task  is  defined,  its  task  ID  will  be  found  in  the  task 
dictionary.  If  it  is  not  defined,  no  FCF  statistics  will  be  accumulated. 

27.  TACMOD  Feature  -  Weather,  Alert,  and  Mission  tapering 

The  weather  delays,  weather  cancels,  alert  replenishment,  alert  release,  and  mission  tapering  features 
all  require  special  input  data  in  columns  74  thru  80  on  the  Form  20s.  These  features  collectively  are 
called  the  TACMOD  features  because  they  were  designed  to  integrate  with  a  TAC  program  called 
CREAT20  which  mechanically  provided  the  Form  20s  with  the  additional  data.  These  features  require 
the  use  of  special  flags  in  both  the  input  and  n  -in  modules  to  activate  the  necessary  logic  and  accept 
the  additional  flying  program  data.  Users  other  than  TAC  can  use  these  features  by  manually  adding 
;  the  additional  data  or  by  obtaining  the  necessary  programs  from  TAC. 

Data  in  Columns  1-73  on  Form  20  remains  standard,  therefore,  users  desiring  to  use  these  features  are 
only  required  to  add  the  proper  information  in  Columns  74-80.  When  the  extra  data  is  present  Column 
2  of  the  Form  20  control  card  (which  contains  the  word  LIST  and  the  keyword)  must  be  a  "T",  i.e.,  LIST 
becomes  LTST.  Also,  to  cause  the  Main  Module  to  use  the  additional  data,  the  TACMOD  change  card 
is  required.  This  change  card  must  precede  the  use  of  any  additional  change  cards  required  to  operate 
the  specific  TACMOD  features. 


The  additional  data  is  described  thus.  Column  74  will  contain  a  data  type  indicator  where:  0=normal 
frag  (Form  20),  l=weather  delay,  2=weather  cancel,  and  3=alert  replenishment  or  alert  release. 
Columns  75-76  contain  the  mission  tapering  value.  Columns  77-80  contain  the  weather  delay  time  in 
minutes.  Since  users  of  these  TAC  options  will  use  Columns  74-80,  it  is  illegal  to  use  the  "T" 
distribution  or  sequence  numbers  on  Form  20s. 

Alert  missions  will  be  handled  in  LCOM  II  in  the  same  manner  as  any  other  mission.  Alert 
replenishments  and  releases,  however,  are  different  in  that  activities  must  be  used.  When  the  aircraft 
completes  this  activity  processing,  it  is  released  a&  a  cocked  aircraft.  This  is  different  from  all  other 
aircraft  activity  processing  in  that  aircraft  are^rele4sed  as  available  aircraft.  The  activities  must  be 
definea  on  the  Form  17.  All  Alert  statistics  are  calculated  and  reported  in  the  designated  alert 
mission  report  column.  I 

Weather  delays  will  be  handled  in  LCOM  II  in  the  same  manner  as  any  other  mission.  However, 
weather  cancels  will  process  through  a  weather  cancel  activity  network.  Because  of  this,  a  weather 
activity  is  required  on  the  Form  17  for  each  mission  which  may  have  weather  cancels.  , 

I 

Users  of  the  TAC  options  must  use  the  Input  Module  to  create  their  exogenous  file.  This  will  allow 
more  edits  and  make  available  more  options  as  well  as  standardizing  the  exogenous  file  creation. 

One  piece  of  information  that  is  not  available  to  the  LCOM  II  input  module  is  an  Activity  report 
column.  Therefore,  the  weather  cancel  report  column  is  input  by  means  of  the  WCXCOL  change  card 
and  the  alert  replenishment  report  column  and  the  alert  release  report  columns  are  input  by  means  of  • 
ALTCOL  change  cards.  Activities,  when  defined  on  the  Form  17  do  not  have  a  specific  report  column 
defined,  thereby  requiring  these  change  cards. 

Mission  tapering  is  an  automatic  non-scheduling  of  missions  when  attrition  and  RAM  have  reduced  the 
number  of  possessed  aircraft  below  a  user  defined  number.  Columns  75-76  of  the  Form  20  contain  this 
value  that  specifies  the  number  of  available  aircraft  at  and  below  which  the  missi  ;.i  tapering  becomes 
effective  for  this  mission.  In  other  words,  this  mission  is  not  scheduled  if  the  current  number  of  j 
available  AC  is  too  low.  The  original  number  of  aircraft  must  have  been  deleted  from  the  simulation  ' 
to  this  value  either  permanently,  by  attrition,  or  temporarily  through  RAM.  Mission  tapering  can  be 
used  to  keep  the  scheduled  sortie  rate  constant  rather  than  allowing  it  to  increase  as  aircraft  are 
removed  from  the  simulation. 

Statistics  are  collected  in  the  main  Performance  Summary  Report  for  the  weather  cancels,  weather 
delays,  alert  replenishments  and  alert  releases.  Values  will  be  zero  unless  these  featues  are  j 
activated,  and  report  columns  specified.  These  statistics  are  updated  at  frag  time  when  the  request  is  * 
initially  read. 

The  TAC  unique  CREATE20  documentation  should  be  read  for  more  detailed  information  concerning 
the  creation  of  weather  delay,  weather  cancel,  alert,  alert  replenishment,  alert  release,  and  mission  ; 
tapering  data. 

28.  SEC1N  (Change  Card  Reading)  Scheduling 

The  reading  of  the  change  cards  provides  a  user  with  a  secondary  initialization  step,  SECIN, 
accomplished  subsequent  to  the  reading  of  the  initialization  file  produced  by  the  input  module.  This 
permits  small  changes  to  be  made  prior  to  the  simulation  and  prevents  the  need  to  continually  rerun 
the  input  phase. 

This  SECIN  is  scheduled  automatically  at  time=0.0,  just  prior  to  starting  the  simulation.  Scheduling 
the  input  of  change  cards  at  other  than  time=0.0  is  accomplished  by  using  a  SECIN  change  card  within 
the  initial  set  of  change  cards.  The  time  is  input  in  integer  days.  One  or  more  SECIN  cards  can  be 
input  at  time  =  0.0  or  at  any  subsequent  SECIN  read-in  time.  See  figure  4-13. 
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For  each  SEC1N  card  used,  an  additional  change  card  file  is  required  with  the  same  rules  for  applying 
to  each  one  as  applied  to  the  first  set.  In  addition  any  change  card  with  a  time  value  on  it,  such  as  a 
report  request,  must  not  have  this  value  less  than  the  time  of  the  scheduled  SECIN  reading  the  card. 
An  abort  will  occur,  i.e.,  simulation  time  decreases.  Also  some  change  cards  are  not  applicable  at  a 
time  other  than  0.0.  Some  edits  are  performed  but  common  sense  should  prevail.  Remember  each  set 
of  change  cards  must  end  with  a  STOP  change  card.  However,  scheduled  SECIN  readings  of  this  card 
always  ignore  this  time. 

Interfacing  this  SECIN  scheduling  feature  and  the  Memory  Dump  and  Restart  feature  can  be  done  by 
properly  integrating  the  sets  of  change  cards. 


29.  FACTOR  -  Form  12  Quantity  Fields  Interpreted  as  % 

Form  12  quantities  fields  (Col  49-45,  53-54,  62-63)  specify  the  exact  quantity  of  a  particular  resource 
that  is  required  on  the  task.  However,  there  is  a  featire  which  permits  the  interpretation  of  quantity 
fields  as  a  percent  (%)  of  time  a  quantity  of  one  is  required.  For  example,  if  the  value  of  the  term 
FACTOR  =  20,  then  any  quantity  on  the  form  12's  greater  than  or  equal  to  20  will  be  interpreted  as  a 
percentage  of  time.  IF  a  task  specifies  resource  N,  quantity  of  20,  it  will  be  interpreted  as:  20%  of 
the  time  the  task  is  done,  a  quantity  of  1  of  the  resource  N  is  needed.  The  remaining  80%  of  the  time 
a  quantity  of  zero  is  needed. 

;  Therefore,  when  resetting  the  default  value  of  FACTOR  (100),  it  must  be  remembered  that  any  Form 
I  12  resource  quantities  greater  than  or  equal  to  the  FACTOR  value  will  be  interpreted  as  percentages. 
;  The  term  FACTOR  is  modified  by  the  change  card  of  the  same  name. 

30.  A,  E,  and  G  Selection  Mode  Relationships 

This  section  provides  a  comparison  of  the  A,  E,  and  G  selection  modes.  These  selection  modes  provide 
a  multitude  of  possibilities  for  modeling  network  branching.  The  description  here  can  obviously  not  be 
all  inclusive.  As  additional  methods  became  popular  or  new  information  becomes  available,  the  section 
will  be  updated.  Several  methods  are  presently  under  consideration  which  when  thoroughly  tested 
could  be  added  here.  The  information  presently  included  is  believed  to  be  accurate  but  not  all 
inclusive.  User  comments  are  solicited. 

a.  Statistical  Comparison  of  A  and  G  Selection  Mode 

The  A  selection  mode  provides  a  method  for  networking  the  situation  where  one  or  more  non-mutually 
exclusive  paths  are  to  be  selected.  The  G  selection  mode  (used  together  with  an  E  selection  mode) 
provides  an  additional  option  for  this  purpose.  The  example  below  will  provide  some  guidance  as  to 
which  mode  should  be  used  for  a  specific  case. 


The  reader  should  note  that  when  the  total  in-shop  failures  are  less  than  the  total  on-equipment 
failures,  the  two  methods  provide  the  same  number  of  hits  against  each  shop  task,  thus  they  are 
equivalent.  The  A  selection  mode  provides  more  instances  of  no  shop  work  and  more  instances  of 
multiple  in-shop  hits  than  does  the  G  with  E  network,  thus  they  are  not  equal. 

Hypothetical  Example  #1:  Suppose  we  have  data  from  100,000  sorties  which  shows  5000  on  equipment 
failures  (hits)  in  the  41 AB*  work  unit  code  area.  Suppose  also  that  the  In-shop  data  shows  700  hits 
against  41  ABA,  600  hits  against  41  ABB,  500  hits  against  41  ABC  and  no  hits  against  any  other  items.  In 
networking  this  subsystem  A  or  G  with  E  selection  modes  can  be  used  to  determine  when  to  go  into  the 
shop  and  what  is  worked  on.  Figures  4-14  and  4-15  illustrate  networks  for  these  two  approaches. 
Table  4-6  compares  the  two  approaches  as  the  number  of  on  equipment  hits  varied  from  2000  to 
20,000. 

It  is  important  to  note  that  in  a  simulation,  the  same  number  of  on  equipment  actions  would  occur 
when  using  either  the  A  or  the  G  selection  modes.  Similarly,  in  the  shop  the  same  number  of  actions 
would  be  performed  against  each  end  item.  The  major  difference  between  the  two  methodologies  is  as 
noted  earlier  in  the  number  of  times  no  shop  work  is  performed  and  in  the  number  of  times  more  than 
one  shop  task  is  performed.  There  are  two  assumptions  implicit  in  the  use  of  the  G  selection  mode. 
All  items  entering  the  shop  for  repair  are  assumed  to  fail  independently  of  one  another  and  the  time 
between  shop  repairs  for  each  item  is  either  geometrically  or  exponentially  distributed.  Many  studies 
have  shown  that  the  failure  law  of  most  items  can  be  closely  approximated  by  the  exponential 
distribution  and  the  geometric  is  simply  the  discrete  analog  of  the  exponential. 


To  use  the  G  selection  mode,  the  on  aircraft  portion  of  the  network  must  be  expanded  as  in  Figure  4- 
14.  The  task  named  E41AB*  in  Figure  4-15  which  represents  all  on  aircraft  work  is  replaced  by  the 
two  tasks  M41AB*  and  R41AB*.  Task  M41AB*  represents  work  that  is  performed  on  aircraft  when  no 
shop  work  follows.  This  is  generally  minor  maintenance  type  work.  Task  R41  AB*  represents  work  that 
is  performed  on  aircraft  when  shop  work  follows.  The  E  selection  mode  probability  (Ep)  for  task 
R41AB*  is  computed  as  follows:  R 


Let  Pj  =  Number  of  shop  hits  on  the  1th  item  divided  by  the  number  of  sorties  in  the  data  bank. 

Let  H  =  The  number  of  on-aircraft  hits. 

Let  S  =  The  number  of  sorties  in  the  data  package. 

Let  P  =  The  product  of  (1-Pj)  (l-P^... 

Then  ER  =  (1-P)  S  and  EM  =  i-ER 

H 

Usually  this  is  a  quick  calculation  because  few  items  are  involved.  This  calculation  determines  the 
correct  number  of  times  the  model  should  enter  the  shop.  In  our  example  above  and  using  the  fourth 
line  in  Table  4-6  (5,000  on  aircraft  hits),  this  calculation  would  be: 


P,  (41  ABA)  =  700  ;  P,  (41  ABB)  =  600  {  P,  (41  ABC)  =  500 

1  njc,w  2  iw,w  3  iwrooo 

Pj  =  .007  P2  =  .006  P3  =  .005 

P,  =  (I-Pj)  (1-P2)  (1-P3)  =  .993  x  .994  x  .995  =  .982 


=  (1-.982)  100,000  =  .36,  and  EM  -  i  -  36  -  64 

5,000 
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Froin  Table  4-6,  it  can  be  seen  that  as  the  ratio  of  total  off-equipment  hits  to  total  on-equipment  hits 
decreases,  the  A  selection  mode  approaches  the  G  selection  mode  in  results,  i.e.,  the  percent  fewer 
shop  entries  decreases  from  27%  to  2%. 


The  G  selection  mode  has  one  major  drawback.  The  G  selection  mode  probability  is  equal  to  P-  for  the 
Ith  item.  This  usually  is  a  very  small  number.  When  the  model  encounters  a  node  with  G  selection 
modes,  it  treats  them  the  same  as  the  A  selection  modes  in  choosing  which  path  or  paths  to  follow, 
except,  if  no  path  is  chosen,  then  the  model  will  loop  back  and  try  again  and  will  continue  looping  until 
at  least  one  path  is  chosen.  It  is  this  looping  which  increases  computer  processing  time  and  it  can  be 
significant  if  the  probabilities  are  small. 

As  can  be  seen  by  comparing  Figure  4-15  where  the  A  selection  mode  is  utilized  with  Figure  4-14 
where  the  G  mode  is  used,  there  is  very  little  difference  in  the  networking  technique.  Some  of  the 
prime  factors  in  deciding  whether  to  use  the  G  vs  A  selection  modes  are:  (l)  How  sensitive  is  the  final 
answer  to  be  derived,  to  the  "independence"  of  failures?  If  very  sensitive,  use  the  G.  (2)  What  is  the 
ratio  of  shop  actions  to  total  on  aircraft  actions?  As  demonstrated  in  Table  4-6  as  the  ratio  decreases 
from  .9,  i.e.,  (1,800/2,000)  in  line  one  to  .09  (1,800/20,000)  in  the  last  line,  the  A  mode  approaches  the 
G.  (3)  How  critical  is  computer  run  time?  Extensive  use  of  the  G  selection  mode  can  increase  run 
time  by  15  percent,  or  more;  however,  if  the  desired  answer  is  sensitive  to  precise  statistical 
treatment  of  the  independence  of  failures  then  the  price  is  worth  the  cost.  The  graph  in  Figure  4-!6 
illustrates  the  reason  for  increased  computer  time  with  increase  in  Ep,  and  reflects  a  plot  of  the  last 
column  in  Table  4-6.  K 
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TABLE  4-6.  A/G  SELECTION  MODE  COMPARISON 


Numbers  of  On 
A/C  Hits  That 
Are  Not  Fol¬ 
lowed  By  Shop 
Work 


Total 

On  A/C 
Hits 

er 

F 

Clock 

Value 

With  A 

With 

2000 

.895 

50.0 

682 

210 

3000 

.597 

33.3 

1533 

1210 

4000 

.448 

25.0 

2454 

2210 

5000 

.358 

20.0 

3406 

3210 

7000 

.256 

14.3 

5349 

5210 

10000 

.179 

10.0 

8305 

8210 

20000 

.090 

5.0 

18253 

18210 

Numbers 

of  On 

% 

// 

Draws 

A/C  Hits 

That 

Fewer 

Required 

Are  Fol¬ 

lowed  By  In¬ 
stances  of  Shop 
Work 

Shop 

Entries 

With 

Per  Cycle 

G/A 

Draw 

With  A 

With  G 

A 

A_ 

G 

Ratio 

1318 

1790 

27 

3 

50.67 

16.56 

1467 

1790 

IS 

3 

34.13 

11.38 

1546 

1790 

14 

3 

25.86 

8.62 

1594 

1790 

11 

3 

20.87 

6.96 

1651 

1790 

8 

3 

15.21 

5.07 

1695 

1790 

5 

3 

10.93 

3.64 

1747 

1790 

2 

3 

5.97 

1.99 

Notes: 


1. 

2. 


Shop  actions  held  constant  at  1800,  (700  +  600  +  500). 

Eo  is  the  probability  of  doing  off-equipment  work,  given  that  a  failure  has  occurred  on  that 
system. 

The  word  draw  refers  to  the  selection  of  a  random  number  by  the  model. 


J 


m 


cusm 


R41 AB* 


^700/ 100, 000  =  ,007 


Er  =  .36 


-X§^ 


41  ABB 


G  =  600/100,000  =  .006 

\»1ABC  _ 

G  =  500/100,000  =  .005 


FIGURE  4-15.  A  SELECTION  MODE  NETWORK 


RATIO  OF  THE  NUMBER  OF  RANDOM  DRAWS  REQUIRED 
(G  SELECTION  MODE/A  SELECTION  MODE) 


ER 


Note:  Graph  plotted  from 
Table  4-6where  shop  actions 
were  held  constant  at  1800, 
as  per  the  hypothetical 
example,  while  the  number 
of  on-equipment  hits  was 
increased  from  2,000  to 
20,000. 


FIGURE  4-16.  G/A  SELECTION  MODE  -  DRAW  RATIO  GRAPH 


b.  Networking  Problems  Involving  A,  E,  and  G  Selection  Modes 

Each  of  the  probabilistic  selection  modes  has  an  area  of  useful  and  correct  application.  The  A  and  E 
selection  modes  utilize  a  conditional  probability  whereas  the  G  selection  mode  utilizes  an  absolute 
probability.  These  absolute  probabilities  are  generally  small  values  requiring  a  multiple  check  of  each 
against  a  random  (fraw.  This  time  consuming  action  has  led  to  extensive  use  of  the  equivalent  (but  not 
equal)  A  selection  mode  networks  in  place  of  the  G  with  E  networks  of  the  example  above. 

Attempts  have  been  made  to  use  the  G  selection  mode  without  the  preceeding  dependent  E  selection 
mode.  Such  attempts  are  also  incorrect.  The  absolute  probabilistic  natire  of  the  G  selection  mode  is 
not  correctly  modeled  without  the  E.  The  following  example  illustrates  a  situation  to  which  the  G 
mode  is  not  applicable. 

Hypothetical  Example  ff2:  Suppose  data  from  10,000  sorties  shows  2,000  failures  in  the  76AE*  work 
unit  code  area.  Suppose  further  that  in-shop  data  shows  240  hits  against  76AEA,  240  hits  against 
76AEB,  960  hits  against  76AEC,  240  hits  against  76AED,  and  720  hits  against  76AEE.  Note  that  this 
totals  2400  shop  actions  for  2,000  on-equipment  fail  .res.  Attempting  to  use  the  G  selection  mode  we 
compute  as  in  Example  #1. 


P1 

(76AEA)  =  240  =  .024 
10000 

P,  (76AEB)  =  240  =  .024 

T5555 

P3 

(76AEC)  =  960  =  .096 
T5555 

Pt  (76AED)  =  240  =  .024 

15555 

Ps 

(76AEE)  =  720  =  .072 

15555 

Pj  =  (1-Pj)  (1-P2)  (1-P3)  <i-P3)  (i-P4)  (i-p5) 
=  (.976)  (  976)  (.904)  (.976)  (.928) 

=  .7799 

ER  =  (1.-.7799)  10000  =1.10 

- 7555 - 


But  we  cannot  have  E  probabilities  greater  than  1.0  and  so  the  G  selection  mode  (which  requires  an  E) 
cannot  be  used.  This  will  happen  whenever  the  to-al  in  snop  hits  exceed  the  on-equipment  hits  by  a 
significant  amount.  The  obvious  way  to  network  this  situation  is  using  the  A  selection  mode  as  is 
shown  in  Figure  4-17. 


The  weakness  in  this  method  is  again  that  the  probability  that  no  shop  will  be  done  is  significant.  Here 
it  is  .2268.  Some  users  desire  more  balanced  shop  utilization  and  thus  model  the  entry  to  shop  work  as 
an  A  in  parallel  to  a  D  selection  mode.  This  is  shown  in  Figure  4-18.  This  method  then  uses  E 
selection  mode  for  the  in-shop  branches. 


76AED 


FIGURE  4-18.  A  AND  D  WITH  E  SELECTION  MODE  METHOD 


The  A  and  E  with  E  selection  mode  method  insures  that  either  1  or  2  shop  tasks  follow  each  on- 
equipment  action.  This  approximates  but  does  not  emulate  the  A  selection  mode  method  since  now 
either  1  or  2  but  not  0,  3,  4,  or  5  paths  may  be  taken. 


For  further  information  on  the  G  selection  mode  refer  to  the  AFMSMET  Publication  78-2  titled  "The  G 
Selection  Mode,  Its  Independent  and  Dependent  Use",  1  June  1978. 


31.  Dump  and  Restart 


The  DUMP  and  RESTART  feature  is  applicable  only  to  the  HIS  LCOM  II  computer  implementation 
since  the  CDC  and  IBM  5IMSCRIPT  II.  5  compilers  do  not  contain  this  capability. 


a.  Basic  Terms 


The  term  DUMP  refers  to  the  capability  of  dumping  onto  a  tape  the  entire  memory  allocated  to  an 
LCOM  II  run  at  specific  times  during  its  execution.  Included  in  this  memory  allocation  are  all  the 
necessary  pointers  to  the  files  assigned  and  opened. 

The  term  RESTART  refers  to  the  capability  to  restore  from  a  tape  (prepared  with  the  DUMP  feature) 
the  entire  contents  of  memory  at  the  point  in  time  the  dump  was  taken,  and  return  to  a  fixed  point  in 
memory  which  will  cause  a  restart  of  the  simulation.  Included  in  this  is  the  complete  repositioning  of 
all  files  except  for  SYSOUT  prior  to  restarting.  Because  of  the  need  to  reposition  all  files  opened,  only 
tapes  and/or  PRMFLs  should  be  used.  See  also  last  para  in  this  description. 

b.  Concepts 


An  LCOM  II  simulation  is  a  time  oriented,  incrementally  processed  set  of  events.  At  periodic  intervals 
of  time  the  computer  software  can  be  triggered  to  make  a  snapshot  copy  (DUMP)  on  tape  of  the  entire 
memory  allocated  to  the  simulation.  The  feature  in  LCOM  II  permits  a  sequential  set  of  these  memory 
dumps  to  be  taken.  For  example,  at  the  end  of  every  3  days  (of  simulation)  a  separate  dump 
(checkpoint)  can  be  taken,  so  that  on  a  dump  tape,  there  would  be  5  separate  dump  files  for  25  days  of 
simulation. 
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A  user  desiring  to  restart  the  simulation  at  any  of  these  checkpoints  may  do  so  by  executing  the 
Restart  Module  designed  to  read  a  specific  checkpoint  from  the  tape,  and  cause  a  restart  of  the 
simulation.  Although  this  restart  program  itself  is  small,  the  same  amount  of  memory  allocated  to  the 
original  simulation  rmfit  be  given  to  this  program  so  that  it  can  reload  the  checkpoint  dumps  into 
memory. 

Where  a  user  makes  no  changes  in  data  thru  additional  Restart  Module  change  cards,  a  restart  run  will 
duplicate  the  original  run  from  the  point  in  time  of  the  restart  itself. 

c.  Dump  Activation 

In  order  to  use  the  dump  and  restart  feature  the  following  conditions  must  exist  in  the  original  Main 
Module  simulation  run: 

(1.)  Only  PRMFLS  and  tapes  have  been  assigned  to  the  active  files,  except,  of  course, 
SYSOUT.  (See  Appenix  A  for  JCL.) 

(2.)  The  "DUMP"  SPEC  card  option  must  be  used  and  it  must  specify  a  unit  upon  which 
the  dumps  are  to  be  taken. 

(3.)  A  dump  t’f'c  must  be  assigned  to  the  specified  unit. 

(4.)  The  simulation  interval  between  taking  dumps  must  be  specified  using  the  RECRD 
change  card  unless  the  default  5  day  interval  is  acceptable.  (See  CHANGE  card  write-up) 

d.  Restart  Activation  , 

To  restart  the  simulation,  the  following  must  exist  in  the  Restart  Module  run: 

(1.)  The  exact  same  PRMFLs  and  tapes  (including  the  Dump  tape)  used  on  the  original 
run  must  be  assigned.  (See  Appendix  A  for  3CL.) 

(2.)  The  exact  same  memory  size  must  be  allocated.  (See  also  last  para  in  this 

description.) 

(3.)  The  CHANGE  cards  for  the  original  run  mist  be  present  and  followed  by  at  least  a 
second  STOP  card  to  control  the  stop  time  for  the  restarted  simulation.  As  implied  here,  a  new  (add¬ 
on)  CHANGE  card  file  is  read  by  the  Restart  Module  upon  restart;  therefore,  new  change  cards  can  be 
used  to  affect  the  results  of  the  restarted  simulation.  They  would  be  placed  between  the  original  stop 
card  and  the  restart  program  stop  card. 

(4.)  The  Restart  Module  through  its  SPEC  card  must  be  told  the  tape  unit  from  which  the 
Dump  tape  will  be  read  and  the  specific  sequential  dump  checkpoint  to  read  prior  to  restart.  This  tape 
must  be  assigned  to  the  same  unit  as  it  was  in  the  original  run. 

e.  Special  Considerations 

Although  stated  earlier,  that  only  tapes  or  PRMFLs  should  be  used,  an  input  $:DATA  file  is  for  all 
practical  purposes  a  permanent  file.  This  is  due  to  the  loading  of  this  file  at  job  read-in  time,  either 
by  the  individual  records  following  the  $:DATA  card,  or  the  use  of  $:SELECT:XXX  or  $:SELECTA:XXX 
3CL  to  load  in  some  specific  data.  However,  all  data  on  this  file  for  the  original  simulation  must  be 
present.  Additional  data  can  be  on  this  file. 

The  Restart  Module,  if  not  told  the  restore  tape  unit  (REST),  will  assume  unit  8  as  its  input. 

The  Restart  Module,  if  not  told  the  checkpoint  number  (CHCK)  to  read,  will  assume  ^he  first  dump  is 
to  be  read. 
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The  time  on  the  Restart  Module  STOP  change  card  (second  stop  card  is  for  the  first  restart)  will 
override  the  original  STOP  card  time.  For  example;  the  original  simulation  run  was  for  40  days  with 
dumps  at  five  day  intervals,  by  restarting  with  the  4th  checkpoint  (day  20)  and  using  a  STOP  card  of 
60,  the  restart  should  run  from  day  20  to  60. 

The  RECRD  change  card  can  also  be  used  to  control  the  length  of  simulation  by  specifying  the  number  ' 
of  additional  dumps  during  the  restarted  simulation.  For  example,  in  restarting  the  above  original  ; 
case,  a  RECRD  card  indicating  8  dumps  at  a  5  (five)  day  interval,  would  cause  the  same  restart  run  of  ; 
20-60  days.  If  RECRD  is  used  in  this  manner,  the  simulation  will  end  at  the  last  requested  dump  ; 
before  the  STOP  card  time  if  the  STOP  card  time  is  greater  than  the  dump  interval.  However,  if  the  ; 
interval  time  on  the  RECRD  card  exceeds  the  STOP  card  time,  the  simulation  will  run  for  the  full  • 
amount  of  time  specified  on  the  RECRD  card.  ' 

Use  of  the  RECRD  option  on  either  the  original  or  restarted  runs  permits  the  changing  of  the  dump  ! 
interval.  It  cannot  eliminate  dumps  from  being  taken,  once  set  up  by  the  use  of  the  DUMP  spec  card  ! 
on  the  original  run.  j 

Those  not  desiring  to  use  Dump  and  Restart  should  not  use  the  DUMP  spec  card  option. 

Sometimes  the  original  run  requires  additional  memory  to  complete,  for  example,  started  with  90K  but 
added  10  extra  pages  (10K)  during  its  entire  simulation.  When  restarting  this  run,  there  is  no  way  of 
knowing  the  exact  allocation  of  memory  at  the  point  of  a  checkpoint  dump  (except  the  last  one).  If  a 
restart  is  attempted  with  the  same  limits  as  the  original  run  and  the  original  run  had  grown  in  memory 
requirements  at  the  point  of  restart,  the  restart  run  will  abort  with  a  F 0  memory  address  fault.  No 
other  indication  of  the  problem  will  be  given.  Therefore,  use  the  maximum  memory  allocated  at  the 
end  of  the  original  run.  Some  unused  memory  may  exist  using  this  technique,  but  is  not  harmful.  Using 
the  example,  restart  any  checkpoint  with  an  allocation  of  100K. 

32.  Resource  Substitution  (Generalized  and  Task  Specific) 

a.  General  Description 

Resoirce  substitution  can  be  specified  in  two  ways  with  LCOM  II;  (1)  as  a  general  resoirce  substitution 
case  where  one  resource  can  substitute  for  another,  or  (2)  as  a  task  specific  substitution  where  a 
resource  or  group  of  resources  can  substitute  for  another  resource  or  group  of  resources. 

The  general  substitution  can  be  applied  to  all  types  of  resoixces,  whereas,  the  task  specific 
substitution  applies  only  to  manpower  resources.  These  two  types  of  resource  substitution  can  be  used 
independently  of  each  other  or  together.  Form  13  must  precede  Form  12  if  Form  12A's  (task  specific  > 
resoirce  substitution)  are  used. 

Each  substitute  or  group  of  substitutes  is  considered  of  equal  ability  in  terms  of  task  performance,  i.e., 
task  time  distribution,  and  priority. 

The  user  may  turn  task  specific  resource  substitution  (Form  12A's)  completely  off  in  a  simulation  run 
even  if  task  dependent  substitute  crews  have  been  defined.  This  is  accomplished  by  placing  a 
NOPOMO  change  card  in  the  change  card  deck.  LCOM  II  will  automatically  pass  the  original  crew  to 
the  task  starting  mechanism  and  ignore  substitute  crews.  Note  that  the  NOPOMO  card  does  not  affect 
general  resource  substitution  of  the  prime  resources. 

b.  General 

General  resource  substitution  is  specified  on  Form  13  along  with  the  resource  definition.  Form  13  has 
additional  data  fields  to  permit  defining  up  to  four  substitutions  on  a  single  Form  13  record.  Also, 
Form  13  continuation  cards  can  be  used,  thereby,  permitting  an  unlimited  number  of  substitute 
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resources  to  be  specified.  Substitutes  are,  however,  placed  on  the  form  in  the  order  of  preference. 
When  processing  these  substitutions  during  simulation,  the  process  will, when  the  original  resource  is 
not  available,  attempt  to  use  the  first  substitute,  then  second,  third.  .  .  last  one  specified.  Controlling 
the  use  of  these  general  substitutions  will  be  discussed  later. 

See  Chapter  VIII,  Section  C,  for  a  description  of  the  Form  13  data  preparation  which  includes  these 
generalized  resource  substitution  fields. 

c.  Task  Specific 

Where  general  resource  substitution  is  not  adequate,  LCOM  II  permits  substitutions  to  be  defined  on  a 
task  by  task  basis.  On  Form  12,  after  the  task  has  been  defined  and  its  manpower  and  non-manpower 
resources  specified,  the  user  can,  by  using  a  Form  12A,  specify  an  entirely  new  manpower  crew 
reflecting  any  necessary  substitution. 

Form  12A  is  not  a  new  form  but  is  only  a  modification  of  Form  12  and  serves  as  a  specialized 
continuation  record  to  further  define  the  tasks  in  terms  of  the  task  specific  crew  substitutions.  As 
such,  only  manpower  resources  can  be  specified  on  Form  12A.  Any  non-manpower  resources  must  have 
been  specified  on  the  original  Form  12  record  for  the  task,  but  will  automatically  be  carried  over  into 
the  task's  resource  requirements  lists  along  with  the  alternate  crew. 

Form  12A  also  modifies  the  meaning  of  three  of  the  Form  12  fields  thus:  (I)  The  associated  resource 
field  (Col  30-35)  can  optionally  be  used  to  specify  the  name  of  a  Resource  Combination  Set  (RCS)  of 
substitute  resources  for  reuse  in  other  12A  records;  (2)  The  consume  fields  (Cols  43,  52,  and  61)  are 
used  on  Form  12A  to  activate  general  resource  substitution;  and  (3)  Column  36  can  be  used  to  control 
the  order  of  use  of  the  Form  12A  records. 

See  Chapter  VIII,  Section  B  for  a  complete  description  of  the  Form  12  and  12A  data  preparation. 

d.  Resource  Substitution  Example 

Figure  4-19  illustrates  use  of  Form  13  and  12/12A  for  the  following  rather  complicated  Resource 
Substitution  example. 

(1)  A  troubleshoot  task  on  the  flight  controls  is  normally  done  by  a  team  of  two  325X0 
autopilot  specialists,  one  431C1  aero  repair  team  chief,  and  one  423X4  hydraulic  specialist.  They  use  a 
D60  power  unit,  hydraulic  mule,  and  B4  stand.  These  requirements  are  listed  on  a  basic  12  card  with 
continuation. 

(2)  Since  one  of  the  autopilot  specialists  merely  observes  control  surfaoe  movement,  he 
may  be  replaced  by  a  431X1  general  mechanic  for  this  task.  This  is  indicated  on  a  Form  12A  which 
specifies  this  Resource  Combination  Set  as  //I  (RCS1).  The  other  325X0  performs  the  autopilot  checks 
and  is  always  required. 

(3)  Each  electrical  (423X0),  hydraulics  (423X4),  ECS  (423X1),  and  engine  (426X2) 
specialist  is  qualified  as  a  general  substitute  for  the  431X1,  as  indicated  on  the  13  card  defining  the 
431X1  resouce.  Col  43  is  marked  on  the  12A  card  to  indicate  that  these  may  be  alternate  substitutes 
for  a  431X1  general  mechanic  on  this  task. 

(4)  The  ECS  specialist  (423X1)  may  also  substitute  for  the  hydraulics  specialist  (423X4) 
on  this  task,  but  not  in  general.  This  is  listed  on  the  second  (RCS2)  and  third  (RCS3)  set  of  Forms  1 2 A. 
(If  423X1  was  a  general  substitute  for  423X4,  it  would  be  listed  as  a  substitute  resource  on  the  423X4 
Form  13  record.  Block  61  would  be  marked  on  the  T14COO  Form  12,  and  the  second  and  third  Form 
12A  would  not  be  necessary.) 

(5)  The  first  time  a  specific  Resoirce  Combination  Set  (RCS)  appears  in  the  data  base, 
the  resources  are  listed  in  full.  For  each  subsequent  use,  resources  would  not  require  redefinition.  See 
task  T42XOO’s  Form  12A  where  RCS1  specifies  the  same  RCS  specifiedon  task  T14COO. 
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e.  Input  Module  Edits 

The  input  module  reorders  the  resource  inputs  entered  on  each  12/12A  record  such  that  the  same 
combination  of  task  resources  are  always  stored  in  the  same  order.  Support  equipment  and  parts  are 
ordered  ahead  of  manpower.  Any  redundant  definitions  of  Resource  Combination  Sets  are  flagged, 
eliminated,  and  replaced  with  the  Resource  Combination  Set's  name  used  in  the  first  place  the  unique 
combination  appeared. 

!  Circular  substitution,  is  a  condition  on  a  particular  Form  12/12A  where  the  use  of  general  substitution 
■  would  result  in  requesting  resources  already  considered.  These  circular  substitutions  when  defined  are 
[  flagged  by  an  edit  in  the  input  module  (MSG  140).  See  error  write-up  for  more  explanation. 

General  resource  substitution  considers  only  those  resources  listed  as  substitutes  on  the  Form  13  for 
the  resource  being  substituted  for,  and  then  only  when  controlled  by  the  X  in  Col  43,  52,  or  61. 

f.  Main  Module  Processing 

(1)  Task  Start  Procedire 

The  main  module  attempts  an  on-hand  balance  scan  for  available  resources  before  formal  starting  of 
each  task.  This  is  accomplished  by  examining  the  on-hand  balance  for  the  primary  resources  listed  on 
the  basic  Form  12  for  the  task.  If  it  is  unable  to  start  because  one  or  more  of  these  primary  resources 
is  not  available,  it  examines  the  on-hand  balance  of  substitutes  in  the  following  order: 

;  (a)  If  general  substitution  activated  for  that  resource,  any  applicable  parts  and/or 

;  support  equipment  substitutes  listed  on  13  records. 

(b)  If  Col  43,  52,  or  61  is  marked  on  the  Form  12,  examine  any  applicable  manpower 
substitutes  in  the  order  listed  on  the  Form  13  records,  treating  as  not  available  those  resources  that 
duplicate  resources  already  considered. 

(c)  If  unable  to  start  because  of  parts  or  support  equipment,  attempt  to  preempt 

(see  below). 

(d)  If  unable  to  start  because  of  manpower  resources,  examine  the  entire  set  of 
manpower  resources  that  are  listed  on  the  next  12A  record(s)  for  the  task.  This  set  would  then  replace 
the  entire  set  of  manpower  resources  listed  on  the  base  Form(s)  12  for  the  task,  but  retain  the  parts 
and  support  equipment  conclusions  reached  in  Step  (a)  above. 

(e)  If  Col  43,  52,  or  61  is  marked  on  the  Form  12A,  examine  applicable  general 
substitutes  listed  on  Form  13  to  replace  any  of  the  manpower  resources  listed  on  the  12A  record  and 
its  continuations. 

(f)  Repeat  (d)  and  (e)  above  for  each  subsequent  set  of  12A  records. 

;  (g)  If  unable  to  start  because  of  manpower,  attempt  to  preempt  (see  below). 

« 

(2)  Preempt  Procedure 

If  unable  to  start  with  primary  resources  or  any  of  the  substitutions  described  above,  attempt  to  start 
the  task  by  preemption  as  follows: 

(a)  Only  tasks  that  can  provide  required  primary  resources  listed  on  the  basic  12 
card(s)  for  the  task,  and/or  their  general  substitutes  as  listed  on  13  cards,  and  have  a  lower  priority 

.  than  the  task  to  be  started  may  be  preempted  to  start  a  task. 

(b)  The  lowest  priority  task(s)  that  can  provide  the  necessary  resources  is  chosen 

for  preemption. 
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(c)  The  maximum  number  of  tasks  that  can  be  preempted  by  priority  category  are 
specified  on  the  Forms  18  with  applicable  defaults. 

(d)  Attempt  to  scan  and  start  preempted  tasks  by  the  same  procedure  as  described 
above.  It  may  be  possible  for  a  preempted  task  to  restart  with  task  specific  substitutes  listed  on  its 
12A  record(s)  ("Ripple"  effects  will  be  very  limited  because  lower  priority  tasks  are  always 
preempted). 

(e)  Preempt  procedure  to  obtain  resources  conform  to  the  standard  procedures 
described  in  Section  15c  except  for  the  limitation  in  (2)(a)  above. 

(f)  Preempted  tasks  are  backordered  in  the  same  manner  as  normal  tasks  if  unable 
to  restart  by  substitution  or  preemption. 

(3)  Bac.kordered/Restart  Procedure 

If  a  task  cannot  be  started  by  resource  substitution  or  preemption,  it  is  placed  in  backorder.  Restart  is 
attempted  by  the  procedure  specified  above  any  time  one  of  the  following  becomes  available: 

(a)  A  resource  listed  on  the  basic  12  record(s)  for  the  task. 

(b)  A  substitute  resource  listed  on  a  Form  13  record  for  a  resource  listed  on  any  12 
and/or  12A  card  with  an  X  in  the  corresponding  column  (43,  52,  or  61). 

(c)  A  resource  listed  on  any  12A  record  for  the  task. 

(4)  Expedite  Procedure 

The  expedite  procedure  is  the  standard  procedure  described  in  Section  15. 

(5)  Performance  Summary  Report  (PSR)  Outputs  See  Figure  9-52. 

New  statistics  have  been  added  to  the  PSR.  The  "Manhours  Used"  statistic  is  broken  down  into 
"Percentage  used  as  a  prime  resource"  and  "Percentage  used  as  a  substitute  resource."  A  substitute  is 
a  resource  defined  as  a  general  substitute  or  defined  as  a  member  of  a  task  specific  substitute  crew 
(Form  12A)  and  not  defined  on  the  original  crew  (Form  12). 

The  "Number  of  Men  Demanded"  statistics  reflect  the  initial  resources  demanded  and  will  include  only 
prime  (Form  12)  required  resources.  The  new  "Number  of  Men  Demanded  Post  Scan"  statistic  reflects 
the  actual  resources  initially  demanded  after  considering  prime  resource  availability.  It  will  include 
both  prime  and  substitute  resources.  The  "Percentage  of  demand'  statistics  have  been  renamed  "% 
Available  By"  to  describe  the  statistic  better.  All  these  subsequent  "%  Avail  By"  statistics  are  now 
computed  based  upon  the  "Nbr  of  Men  Demanded  Post  Scan"  statistic. 

(6)  Post  Processor  Tapouts 

The  main  module  tapouts  provide  necessary  data  for  the  Manpower  Matrix  Post  Processors.  Prime  and 
substitute  resource  statistics  displayed  are  described  in  Chapter  V,  Section  D. 

33.  Time  Controlled  Activ'ty  Processing 

Activities  are  placed  on  the  schedule  (exogenous  file)  by  the  Input  Module  at  the  activity  time 
specified  on  Form  20.  Each  aircraft  or  non-aircraft  resource  requested  on  Form  20  which  is  available 
at  frag  time/activity  time  begins  processing  independently  of  any  additional  resources  requested  for  , 
the  activity.  In  other  words,  the  number  entered  in  the  max  field  on  the  Form  20  for  an  activity  I 
causes  the  Main  Module  to  attempt  to  start  that  number  of  individual  activities.  At  cancellation  time  ! 
only,  the  activities  with  an  unfilled  resource  request  are  cancelled.  Activities  will  not  be  cancelled 
once  the  resource  requested  on  the  Form  20  is  assigned,  even  if  a  reconfiguration  network  is  processed 
prior  to  the  activity.  See  Chapter  VIII  for  details  of  filling  out  Form  20s  for  activities. 
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C.  Output  Products 

There  are  two  specific  outputs  of  the  Main  Module.  They  are:  (1)  simulation  reports  for  the  entire 
length  of  the  simulation,  and  (2)  a  transaction  file  which  is  processed  by  the  post  processor  system. 

Included  in  the  simulation  reports  are: 

1.  A  print-out  of  the  SPEC  card  selected  run  options. 

2.  A  print-out  of  the  change  card  file  as  processed. 

3.  Embedded  diagnostics  of  a  warning  nature. 

4.  Performance  Summary  Reports  at  the  specified  intervals  of  time. 

5.  Other  user  selected  output  reports. 

6.  Timing  and  job  processing  statistics  at  end  of  run. 

7.  Applicable  diagnostics  and  trace  back  information  upon  any  abort. 

D.  Specific  Output  Reports 

1.  SPEC  Card  Information  -  See  Figure  9-40. 

All  of  the  run  specification  (SPEC  Card)  options  either  selected  by  the  user  or  defaulted  are  listed 
under  this  title.  Included  are  any  parameters  or  file  assignments  associated  with  the  option.  The 
report  is  automatic.  See  Chapter  VI  for  details  of  all  Main  Module  SPEC  card  options. 

2.  Initialization  Data  Report  -  See  Figure  9-41 

This  report  is  a  programmer  oriented  report  which  contains  all  the  initialization  information  produced 
by  the  Input  Module.  There  is  no  actual  report  heading,  but  its  first  entry  is  CONTR.DV  and  some 
number  which  will  equal  the  size  of  the  control  table  as  reported  in  the  Input  Module  run. 

This  report  is  automatically  provided  by  the  Main  Module  for  program  debug  purposes.  However,  it  can 
be  diverted  to  a  print  file  by  using  the  DATA  option  on  the  SPEC  card.  This  print  file  can  be  either  a 
tape,  permanent  file,  or  a  temporary  file.  However,  if  a  programmer  oriented  problem  arises  and  the 
file  was  a  temporary  file,  the  needed  data  will  have  been  lost  and  a  rerun  required. 

Unless  specifically  asked  for  information  from  this  report,  users  should  normally  ignore  the  data  within 
it,  if  printed,  or  should  direct  it  to  some  other  file. 

3.  Change  Card  Report/Aircraft  Identity  Dictionary 
a.  Change  Card  Report.  See  Figure  9-42. 

This  report  lists  all  the  Change  Card  input  for  the  run.  The  report  is  headed  by  the  title  "The  following 
variables  were  changed  in  SECIN."  SECIN  is  the  routine  that  processes  all  the  Change  Cards.  The 
report  is  automatically  provided. 

Embedded  within  this  report  will  be  warning  diagnostics  when  a  Change  Card  or  one  of  its  parameters 
were  incorrectly  input.  Sometimes  a  default  will  be  used  with  a  message  informing  what  default  was 
used.  Other  messages  indicate  the  card  itself  was  ignored.  If  an  illegal  Change  Card  name  is  used,  the 
run  will  abort. 

Normally,  the  diagnostic  will  print  after  the  Change  Card  unless  the  card  itself  is  incorrect  or  bad  data 
such  as  alpha  information  is  found  in  the  integer  (IPAR  &  IPAR2)  or  real  fields  (FPAR  <5c  FPAR2).  In 
this  case  the  system  will  abort  the  run  because  of  read  difficulties.  Therefore,  it  is  important  that  no 
illegal  data  (comment)  be  placed  on  the  Change  Cards  anywhere  within  Column  I  through  Column  50. 
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b.  Aircraft  Identity  Dictionary.  See  Figure  9-42a. 

This  report  lists  the  sequence  number,  tail-number,  and  tracking  time  interval  of  all  the  aircraft  that 
have  to  be  authorized.  Embedded  within  this  report  will  be  diagnostic  messages  indicating  overlapping 
tracking  time  intervals.  If  they  are  encountered  then  the  second  TRAKAC  change  card  request  will  be 
ignored. 

4.  Exogenous  Data  Report  -  See  Figure  9-42  , 

This  is  only  a  one  line  report  which  always  follows  the  printing  of  the  SECIN  change  cards.  It  states 
"EXOG  EVENT  TAPE  XXXXX  BEING  USED  -  COMMENT  DATA."  The  XXXX  refers  to  the  keyword 
placed  on  the  LIST  card  (2nd  card)  in  the  Form  20s  that  produced  the  flying  program  exogenous  file  and 
the  "Comment  Data"  is  that  information  on  the  same  LIST  card  following  the  keyword. 

This  report  makes  it  easy  to  track  which  exogenous  file  was  used  for  the  run  when  multiple  flying 
program  scenarios  are  used.  It  is  always  provided  automatically. 

5.  Failure  Clocks  -  See  Figure  9-43 

This  report  titled  "Failure  Clocks"  prints  only  when  the  SW1CH  change  card  is  used  to  turn  SWICH  11 
equal  to  1.  The  report  follows  the  Exogenous  Data  Report  and  begins  on  a  new  page.  The  column 
headings  and  their  meanings  are: 


Headings 


Description 


MEAN 


VARIANCE 


INITIAL  VALUE 


Dictionary  number  of  the  failure  clock. 

I 

The  distribution  type  where;  0  or  10  =  constant,  1  =  normal,  2  = 
poisson,  3  =  erlang,  4  =  wiebull,  5  =  exponential,  6  =  lognormal,  9  = 
empirical,  and  greater  than  10  =  triangular. 

Applicable  mean  value  in  days  or  a  decimal  value. 

Applicable  variance  value  in  days  or  a  decimal  value,  per  the 
distribution  type.  For  a  triangular  distribution,  it  is  the  sum  of  the 
optimistic  and  pessimistic  values. 

That  value  drawn  from  the  distribution  described. 


RANDOM  VALUE 


%  VAR  =  PESS 


The  initial  value  multiplied  by  a  random  percentage  -  to  simulate 
starting  at  a  value  less  than  the  initial  draw. 

The  percent  of  the  variance  that  represents  the  pessimistic  value  for 
triangular  distributions. 


The  random  value  is  the  starting  value  for  all  clocks  in  the  network. 

6.  Task  Time  Distributions  -  See  Figure  9-44 

This  report  contains  no  general  heading,  but  prints  immediately  after  the  Failure  Clock  Report  if  the 
SWICH  //l  l  set  equal  to  1.  The  report  is  primarily  diagnostic  in  natire,  in  that,  once  seen  for  a 
simulation  run,  it  is  usually  not  asked  for  again.  This  is  partially  due  to  its  volume  and  limited 
usefulness  on  subsequent  runs. 

It  primarily  is  a  report  used  to  validate  if  proper  task  times  were  input.  It  reflects  the  highest  and 
lowest  possible  random  task  times  and  reflects  the  entire  spectrum  of  the  task  time  distribution. 
Column  headings  are  produced  only  on  the  first  page  of  output. 
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Heading 

Description 

TASK 

Task  ID  number  from  task  dictionary. 

TMEAN 

Task  mean  value  as  input  (in  days). 

LOG  (MEAN) 

The  log  of  the  mean  when  applicable  for  model  use  (normal  <5c  lognormal 
values  only). 

TVAR 

The  variance  value  as  input  (in  days).  For  triangular  distribution, 
contains  the  sum  of  the  optimistic  or  pessimistic  values. 

HIGH  DRAW 

This  value  (in  days)  reflects  the  highest  random  draw  for  the  task 
time  based  upon  the  mean  variance  values.  For  empirical  distribution, 
many  draws  are  made  to  insure  this  represents  the  highest  value. 

LOW  DRAW 

The  opposite  of  the  above. 

(%  TVAR  =  PESS) 

The  percent  of  the  TVAR  value  that  represents  the  triangular  distribution 
pessimistic  value.  The  remainder  of  TVAR  is  the  optimistic  value. 

A  general  review  of  these  High  Draw  -  Low  Draw  and  Mean  Fields  will  give  users  confidence  on  the 
spread  of  their  input  task  time  distributions.  Unwanted  distribution  spreads  should  be  changed  on  the 
Form  12  task  inputs. 

7.  Performance  Summary  Report  -  See  Figures  9-51  and  9-52. 

,  This  Performance  Summary  Report  (PSR)  represents  the  primary  output  product  of  LCOM  II.  It 
I  consists  of  75  overall  performance  statistics,  divided  into  the  following  six  groups. 


Groups 

No.  Stats 

Resource  Info  Collected  On 

Operations 

14 

Missions 

Aircraft 

14 

Aircraft 

Personnel 

16 

Men 

Shop  Repair 

8 

Parts 

Supply 

10 

Parts 

Equipment 

13 

AGE  (ground  equipment) 

The  report  is  triggered  and  frequency  controlled  through  either  the  Form  10  subtype  01  input  record  or 
the  RFREQ  change  card. 

Referring  to  the  example  in  Figure  9-51,  there  is  one  row  of  data  for  each  of  the  75  statistics.  Aside 
from  the  "TOTAL"  column,  the  columnar  headings  may  be  different  for  each  of  the  six  groups.  The 
user  controls,  through  Form  10,  what  is  printed  as  columnar  headings  of  the  PSR.  See  Chapter  VIII  for 
details  about  preparing  Form  10. 

In  general,  statistics  are  accumulated  during  the  simulation  and  assigned  to  a  particular  column  of  the 
report  according  to  the  value  of  a  parameter.  For  most  of  the  statistics,  this  parameter  is  a  column 
number  assigned  to  each  resoirce  item  on  Form  13.  If,  for  example,  it  is  desired  that  columns  for  the 
Supply  portion  of  the  report  represent  individual  supply  items  (Parts),  then  each  part  would  be  assigned 
a  separate  column  and  then  column  headings  for  these  items  would  be  specified  on  Form  10.  For 
groupings  of  supply  items,  then  each  supply  item  in  that  group  is  assigned  a  number  representing  the 
column  under  which  the  item's  supply  statistics  are  to  be  accumulated.  If  unit  cost  or  demand  rate 
categories  are  desired,  rather  than  Work  Unit  Codes,  then  the  appropriate  category  number  may  be 
assigned  to  each  supply  item,  causing  its  statistics  to  be  accumulated  and  presented  in  the 
corresponding  column  of  the  report. 
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Similar  procedires  apply  to  the  other  groups  of  statistics.  Manpower  statistics  may  be  individually 
reported,  grouped  by  shop,  by  skill  level,  by  AFSC  groupings,  etc.  Aircraft  statistics  may  be 
distributed  by  aircraft  type,  by  squadron,  etc.  Aggregations  of  these  kinds  are  limited  only  to  the 
extent  that  resource  items  can  be  assigned  to  columns  of  the  report.  There  is  no  limit  on  the  number 
of  columns  that  may  be  used,  except  that  imposed  by  the  computer  storage  capacity.  If  more  than  10 
columns  are  used,  the  remaining  columns  will  appear  in  repetitions  of  the  group  until  all  columns  are. 
printed. 

The  main  exception  to  this  procedure  is  for  statistics  in  the  Operations  group.  Here,  the  columnar 
split-out  is  controlled  only  by  mission  type  on  Form  17.  The  user  still  has  the  freedom,  however,  of 
defining  mission  types  however  he  pleases  and  labeling  the  column  headings  to  correspond. 

The  Input  Module  automatically  provided  one  additional  column  called  "other"  for  each  section  of  the 
report.  When  processing  the  column  assignments  on  Form  13  or  17,  any  erroneous  or  blank  column 
assignments  will  automatically  default  to  this  other  column. 

Column  headings  for  each  resource  can  be  changed  in  the  MAIN  module  by  the  RPCOL  change  card. 
Alert  replenishment  and  alert  release  activity  column  headings  are  set  with  the  ALTCOL  change  card; 
the  weather  cancel  report  column  is  set  with  the  WCXCOL  change  card. 

For  any  given  run  of  the  Main  Module,  the  Performance  Summary  Report  may  be  produced  in  two 
levels.  The  Level  I  reports  are  produced  automatically  on  a  periodic  basis  as  specified  by  the  user: 
every  day,  every  other  day,  every  week,  etc.  Statistics  shown  in  this  report  represent  performance 
during  the  indicated  period.  The  Level  11  reports  are  produced  for  a  given  multiple  of  the  Level  I 
reports  by  using  the  RCYC  change  card  and  contains  summary  statistics  over  the  longer  time  period. 
Thus,  Level  I  reports  may  be  produced  each  day,  with  Level  II  reports  representing  7-day  summaries;  or 
Level  I  reports  may  appear  weekly  with  Level  II  reports  containing  4-week  summaries,  etc.  The 
formats  of  the  Level  II  reports  are  identical  to  those  of  Level  I;  the  only  difference  between  the  two 
levels  is  in  the  time  period  over  which  the  statistics  is  aggregated. 

Most  of  the  line  entries  on  the  Performance  Summary  Report  are  more  or  less  self-explanatory.  For 
any  line  entry  with  "100"  or  "1000"  shown  in  parenthesis,  the  corresponding  data  should  be  multiplied 
by  this  number.  For  example,  data  for  Total  Dollar  Investments,  Lines  54  and  68,  is  printed  in 
thousands  of  dollars.  Where  an  "EOP"  appears  in  parenthesis,  the  statistic  represents  status  as  of  the 
end  of  the  reporting  period  as  shown  in  the  report  heading.  All  other  line  entries  represent  statistics 
accumulated  during  the  reporting  period. 

Statistics  are  actually  numbered  sequentially  by  the  MAIN  module.  However,  the  LCOM  I  statistic 
numbers  are  still  printed  for  programmer  tracking  and  debug.  Future  versions  of  the  MAIN  module  will 
eliminate  these  numbers  and  substitute  the  actual  numbers.  See  Decoder  Output  Figure  5-2  for  actual 
statistic  number  assignments.  For  the  time  being,  the  number  printed  should  be  referred  to  as  the  "Old 
Stat  Number." 

Some  of  the  statistics  have  special  interpretations  in  accordance  with  the  way  in  which  they  are 
computed.  These  statistics  are  further  described  individually  in  Appendix  G  using  the  "Old  Stat 
Numbers"  as  references. 

8.  Resource  Data  Report  -  (ITEM)  -  See  Figure  9-47 

This  report  must  be  requested  by  using  the  ITEM  change  card.  Since  it  is  a  snapshot  report,  it 
represents  the  resource  conditions  "as  of"  a  point  in  time.  Therefore,  multiple  Item  change  cards  can 
be  used  specifying  the  exact  time  in  simulation  days  that  this  report  is  to  be  printed. 

The  report  is  described  as  follows: 
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Column  Heading 
RES  NUMBER 
REPORT  COLUMN 
RESOURCE  TYPE 
NUMBER  OF  SUBST 
RES  COST 
AUTH  QUAN 

ON  HAND  BAL 
DUE  IN  BAL 

DUE  OUT  BAL 


Description 

The  dictionary  assigned  number  for  the  resource. 

The  PSR  report  column  where  this  resource's  statistics  are  collected. 

Aircraft,  men,  parts,  AGE,  or  other. 

Number  of  general  substitutes  this  resource  has. 

Input  cost  for  this  resource,  largest  print  value  is  999936.00. 

Current  authorized  quantity.  Does  not  reflect  a  value  for  those 
resources  on  a  shift. 

The  number  on-hand,  i.e.,  those  serviceable  items  not  in  use. 

The  due-in-balance,  i.e.,  the  number  of  items  to  be  replaced 
in  the  on-hand  pool. 

The  due-out-balance,  i.e.,  those  items  for  which  a  demand  has 
been  recorded  but  not  yet  filled. 


NO.  OF  DEMANDS 

CUTIL  FACTOR 


UTIL 


The  number  of  demands  that  have  been  made  on  the  resource 
since  simulation  began. 

An  indication  of  the  utilization  of  this  resource  since  the  simulation 
began.  A  negative  value  indicates  that  there  has  been  more 
waiting  for  this  resource  than  there  has  been  time  that  the  spare 
resource  was  available. 

The  utilization  index  computed  from  CUTIL.  Should  always 
be  zero. 


USHP 


Indicates  row  in  the  shift  table  containing  the  resource  authorizations. 
It  will  be  zero  for  resource-  not  on  shift. 


LAST  TIME  OF  UPDATING  The  time  that  CUTIL  was  last  incremented  or  decremented. 

Through  this  report  the  networking  of  resoirce  utilization  and  resource  balancing  within  the  simulation 
can  be  verified,  i.e.,  for  each  consume  there  was  a  generate;  resources  balance  with  the  formula 
AUTH  =  ON-HAND  +  DUE-IN;  also,  resource  demand  patterns  can  be  evaluated  by  requesting  multiple 
reports. 

Non-manpower  constraining  effidendes  can  be  reviewed  with  the  CUTIL  FACTOR.  Values  slightly 
above  zero  indicate  good  constraining.  High  values  indicate  poor  constraining  and  negative  values 
indicate  over  constraining.  Users  must  work  with  this  statistic  in  conjunction  with  the  authorized 
quantity  and  no.  of  demands  to  establish  meaningful  statistical  values  as  limits  for  this  general 
constraining  evaluation. 

The  last  resource  (row)  listed  in  this  report  has  a  resource  type  of  other.  This  is  an  automatically 
•  assigned  resource  the  Main  Module  uses  when  users  place  a  generate  on  Form  12  (asterisk  in  Col  29) 
and  leave  the  assodated  resource  field  (Columns  30-35)  blank.  Users  should  not  be  concerned  with  this 
resource  unless  the  value  exceeds  the  authorized  quantity  of  9999.  An  AUTH  change  card  can  modify 
this  default  quantity.  The  AUTHA  card  also  affects  it. 
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This  report  is  titled  the  Aircraft  Class/ Configuration  Report  and  provides,  in  a  matrix  format,  the 
number  of  aircraft  actually  in  each  external  configur  ation  at  the  user  specified  request  time.  Within 
each  class,  the  total  is  broken  down  by  aircraft  status  (i.e.,  'Ready,'  'Cocked,'  'Processing').  The 
columns  of  the  matrix  represent  the  ^rcraft  configurations.  From  left  to  right,  the  first  column  under 
the  word  CLASSES  represents  the  first  configurations  defined  on  the  Form  17  and  the  last  column 
represents  the  last  configurations  defined  on  the  Form  17  (if  only  six  configurations  were  defined, 
there  would  be  only  six  Class  Columns  in  the  report).  Each  row  represents  an  aircraft  flag  status. 
Table  4-3  describes  all  the  aircraft  status  flag  values.  This  information  will  aid  in  interpreting  the 
QSTAT  Report.  The  first  three  rows  represent  the  basic  flag  values  of  'Ready'  (0),  'Cockecf  (20),  and 
'Processing'  (greater  than  20).  Subsequent  rows  in  the  Detail  Report  Portion  provide  an  expanded  look 
at  the  "Processing"  row  (row  3).  Class  and  flag  status  totals  are  provided  to  the  right  of  the  first  3 
rows  as  well  as,  total-on- hand,  total  authorized,  and  the  total  number  of  outstanding  aircraft  requests 
not  yet  satisfied. 

The  first  configuration  (Column  1)  is  the  configuration  the  aircraft  are  in  at  the  beginning  of  the 
simulation.  Multiple  QSTATS  during  the  simulation  provide  an  insight  as  to  what  is  happening  to  the 
aircraft. 

An  important  use  of  the  QSTAT  report  is  to  assist  the  analyst  in  locating  errors  in  the  Forms  17  and 
21.  A  build-up  or  pooling  of  aircraft  in  any  configuration  indicates  that  one  or  more  of  the  search 
patterns  may  need  to  be  modified,  otherwise,  serious  bottlenecks  of  aircraft  availability  will  occur. 

Conversely,  the  QSTAT  report  will  be  most  helpful  to  users  wanting  to  create  a  pooling  effect  of  a 
specific  aircraft  configuration.  This  pooling  might  be  for  special  alert  pooling,  etc.  The  QSTAT  report 
can  verify  that  the  proper  action  was  being  taken. 


10.  In-Process  &  Backorder  Status  Reports  -  (IPSTAT  and  BOSTAT)  -  See  Figures  9-4  S  and  9-49. 

These  reports  give  information  on  all  tasks  in  the  system,  both  those  being  accomplished  and  those 
which  are  waiting  to  be  accomplished.  They  are  not  automatic  reports.  They  must  be  triggered  by  the 
IPSTAT  and  BOSTAT  change  cards.  They  are  snapshot  reports  and  thus  provide  only  an  "as  of"  status. 
The  column  headings  are  generally  self-explanatory  but  are  described  as  follows: 


Column  Heading 
TASK  ID 
JOB  PRI 

NEXT  INDEX 

RES  ID 
TIME  IN 

TYPE  OF  RES 
AC  FLAG 

ID 

QTY 


Description 

Dictionary  number  assigned  the  task. 

Individual  job  priority,  not  the  group  priority  assigned  on  Form 

12. 

The  Index  of  the  control  table  where  the  subsequent  task  is 
located. 

The  dictionary  identity  of  the  resource  that  is  being  processed. 

On  IPSTAT  report  =  time  job  started.  On  BOSTAT  report  = 

0.0. 

Type  of  resource;  aircraft,  men,  parts,  or  age  that  is  processing. 

If  aircraft  is  processing  =  the  Status  Flag  value.  For  non-aircraft 
resources  =  0. 

Required  resource  used  on  job. 

Quantity  of  above  resource  required.  If  negative,  resource 
is  to  be  consumed. 
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NOTE:  Remainder  of  columns  are  programmer  oriented  data.  Contact  programmer  for  information 
about  these  if  required. 

11.  Mission  Status  Report  (MNSTAT)  -  See  Figure  9-45. 

This  report  provides  a  snapshot  view  of  the  "as  of"  status  of  the  outstanding  missions,  either  still 
required  or  in-process.  The  report  is  not  automatic  and  requires  triggering  by  means  of  a  MNSTAT 
change  card.  There  can  be  multiple  requests  for  this  report.  The  report  is  automatically  triggered  the 
first  10  times  that  diagnostic  message  510  is  printed  and  will  aid  in  establishing  proper  Form  21 
records.  The  column  headings  on  this  report  are  described  as  follows: 

Column  Heading  Description 

ID  The  identification  of  the  mission,  used  by  the  Main  Module. 

TYPE  Mission  type,  defined  by  user. 


NAME 

PRI 

MIN 

MAX 


Alpha  Name  given  this  mission  on  Form  17. 

The  priority  of  the  mission  (from  Form  20). 

<r 

The  minimum  number  of  aircraft  which  must  be  available  for 
mission  accomplishment. 

The  maximum  number  of  aircraft  that  were  requested  for  the 
mission. 


T/O  TIME 

Scheduled  take-off  time. 

DURATION 

Diration  of  the  mission. 

CANCEL-T 

The  allowable  waiting  time  before  cancellation  of  the  mission 
(hours  after  T/O  time).  (In  days  &  hours  <Jc  minutes  format.) 

TRN 

The  internal  reference  identification  (tail)  numbers  of  those 
aircraft  assigned  to  the  mission. 

RES.ID 

The  ID  of  the  aircraft  type  (from  Resource  Dictionary).  If 
value  is  negative,  the  TRN  number  is  still  the  request,  not  the 
aircraft  tail  number,  aircraft  has  not  yet  been  assigned. 

STATUS 

The  status  flag  of  each  aircraft  (see  Figure  4-3). 

NAME 

Alpha  name  of  aircraft  type  (Res  ID). 

12.  Most  Trouble  Report  -  See  Figure  9-50 
This  report  is  not  implemented  completely.  It  will  always  contain  zeros. 


13.  HIT  MATRIX  Report  -  See  Figure  9-53 

The  HIT  Matrix  Report  is  a  summary  by  Control  Table  Index  of  the  actual  results  of  the  simulation 
period  specified  for  the  report.  It  contains  the  number  of  times  that  a  particular  node  (Control  Table 
Index)  was  reached,  and  the  number  of  times  the  task  at  that  node  was  set  up.  All  applicable 
parameters  are  printed  in  the  report  as  an  aid  to  interpretation.  A  substantial  amount  of  information 
can  be  obtained  from  the  report  as  to  how  the  network  processed.  Tasks  controlled  by  Failure  Codes 
can  be  validated  as  to  proper  quantities,  processing  of  A  and  E  selection  parameters  can  be  verified, 
etc.  The  HIT  Matrix  Report  is  structured  on  a  page-by-page  basis  exactly  like  the  Control  Table 
Dictionary  for  easy  cross  referencing. 
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a.  Data/Report  Activation  -  See  CHANGE  Card  Specification 

(2)  The  collection  of  HIT  MATRIX  data  for  a  particular  interval  of  time  is  implemented 
by  using  a  HITMAT  change  card.  The  time  the  collection  of  data  is  to  begin,  and  the  time  the 
collection  is  to  stop  is  specified  on  the  HITMAT  card.  At  the  stop  time  the  HIT  MATRIX  report  is 
printed  and  the  matrix  is  cleared.  The  user  may  schedule  several  HIT  MATRIX  reports  during  a 
simulation  by  inputting  a  different  HITMAT  card  for  each  report. 

CAUTION:  The  time  interval  specified  on  the  HITMAT  change  cards  for  an  individual  simulation  run 
cannot  overlap.  The  first  card  read  for  a  reporting  period  will  be  implemented,  and  the  other  cards 
during  the  same  period  will  be  ignored. 


b.  Interpretation  of  Report  Headings 
Report  Titles  Description 

FROM  BRANCH  Control  table  row  indices  where  processing  has  reached. 


TO  BRANCH 
ALT  BRANCH 
TASK-ID 


Control  table  row  index  for  the  next  task. 

Control  table  row  index  for  the  first  parellel  task. 

Dictionary  ID  of  the  task  attempted  to  be  processed  at  the 
particular  row  position  in  the  control  table. 


PROC  ATTEMPT 

PROC  IN  IT'D 


PARAM  VALUE 


M 


c.  Special  Notes 


A  counter  indicating  the  number  of  times  the  particular  control 
table  row  has  been  reached  (Process  Attempted). 

Counter  indicating  the  number  of  times  the  task  on  the  particular 
control  table  row  was  set-up  (Process  Initiated).  Set-up  does 
not  always  mean  started  or  completed.  The  task  could  be  completed 
or  in-process  at  the  time  of  the  report  or  could  have  been  set¬ 
up,  then  placed  in  backorder  because  of  resource  non-availability. 
SETUP  does,  however,  mean  that  the  task  will  be  accomplished 
during  the  simulation  when  resources  are  available. 

This  is  the  parameter  value  of  the  particular  control  table  row 
position.  Applicable  only  on  A,  E,  and  G  selection  modes. 

The  defined  selection  mode  for  the  particular  table  row. 


Several  processing  features  in  the  Main  Module  cause  the  counts  in  the  PROCESS  ATTEMPT  and 
INIT'D  columns  to  be  other  than  what  might  be  expected.  By  understanding  these  differences,  a  good 
deal  of  insight  into  the  processing  results  can  be  obtained.  The  processing  feature  and  its  effect  on 
these  counts  are: 


(1)  Timing  of  when  the  HIT  MATRIX  standup  time  is  requested  -  affects  the  time  when 
counts  are  made.  For  example,  in  a  network  with  a  sequence  of  tasks  -  A,  B,  C,  D,  if  the  HIT  MATRIX 
start  up  time  happened  between  the  processing  of  B  and  C,  the  counts  of  A  and  B  would  be  lower  than 
C  and  D.  This  effect  will  be  more  apparent  on  HIT  MATRICES  started  at  a  time  other  than  zero,  e.g., 
subsequent  HIT  MATRICES. 
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(2)  In  order  to  speed  up  processing,  the  Main  Module  attempts  to  skip  over  any  branch 
with  a  dummy  task  on  it.  This  cannot  be  done  easily  if  the  branch  has  a  parallel  task,  therefore,  often 
only  the  final  parallel  branch  in  a  set  is  skipped  over  and  not  counted.  This  affects  the  last  in  a  set  of 
parallel  Es,  As,  or  Gs  if  the  tasks  defined  are  dummys.  No  INIT'D  count  can  thus  be  taken.  Thus,  with 
two  E  branches  with  20  and  50  percent  respectively,  no  task  defined  on  each  branch,  and  a  count  of  100 
on  each  branch's  PROCESS  ATTEMPT,  the  PROCESS  INIT'D  will  be  20  on  the  first  branch  and  ZERO 
(0)  on  the  last. 

(3)  When  the  aircraft  reach  the  sortie  task  and  scheduled  take-off  time  has  not  been 
reached  or  not  enough  aircraft  are  available,  the  model  causes  the  aircraft  to  wait.  Subsequently,  at 
mission  time,  the  aircraft  are,  in  effect,  reinserted  in  the  network  at  the  sortie  task  causing  the 
PROCESS  ATTEMPT  count  to  be  increased.  This  effect  can  result  in  a  count  of  the  PROCESS 
ATTEMPTS  double  that  of  the  PROCESS  INIT'D  on  the  sortie  task.  Some  inferences  can  be  made  of 
the  relationship  between  the  ATTEMPT  (A)  and  the  INIT'D  (I)  counts.  With  "A"  double  "I"  all  aircraft 
are  Pre-Sortie  processing  in  less  than  scheduled  take-off  time  minus  FRAG  time.  The  closer  these 
numbers  agree  and  the  mission  MAX  A  aircraft  equals  one,  the  more  aircraft  are  taking  the  entire 
lead  time  to  process  pre-sortie  tasks.  This  A/I  relationship  is,  of  course,  affected  by  the  MAX  aircraft 
parameter. 

(4)  The  Main  Module  wants  to  directly  assign  cocked  aircraft  to  the  sortie  task  but  since 
it  has  only  the  entry  point,  it  must  insert  the  cocked  aircraft  at  that  point.  In  this  case,  the  dummy 
task  is  inserted  for  each  pre-sortie  task  and  therefore,  these  pre-sortie  tasks  are  not  processed,  in 
effect  skipped.  No  count  of  them  will  be  taken  on  the  INIT'D,  but  the  ATTEMPT  will  reflect  the  count 
including  the  cocked  aircraft. 

(5)  Several  additional  analysis  items  are  sure  to  be  discovered  and  the  HIT  MATRIX  will 
reflect  them  in  some  way  or  another,  probably  for  the  benefit  of  user  analysis. 

d.  Use  Considerations 

The  use  of  this  option  by  the  user  as  a  debugging  tool  cannot  be  overstated.  It  must  be  used  to  insure 
correct  networking  and  that  a  long  enough  sample  has  been  simulated.  If  the  initiated  count  does  not 
approximate  the  percent  values  represented  by  the  A,  G,  or  E  selection  modes,  the  networking  is 
incorrect  (not  reaching  that  point  correctly)  or  the  number  of  days  simulated  is  not  enough  to  obtain  a 
representative  sample. 

e.  Report  Costs  to  the  User  Are; 

(1)  Core  equal  to  the  control  table  size  is  required,  e.g.,  5000  control  table  entries  cost 
an  extra  5K  in  the  run. 

(2)  Reports  will  be  printed  down  the  page  split  into  two  halves.  Therefore,  print  costs 
vvill  be  equal  to  1/2  the  length  of  the  control  table,  e.g.,  for  the  above  example,  the  print  lines  will  be 
2500  plus  titles  on  each  page. 

14.  Programmer  Level  Reports 

There  are  three  basic  programmer  reports.  They  are:  (1)  an  Aircraft  Transaction  Display,  (2)  the 
Software  Routines  Entry/Exit  Display,  and  (3)  Full  Transaction  Display.  Briefly,  they  are  described  as 
follows: 

a.  Aircraft  Transaction  Display 

This  report  is  triggered  with  the  DSPLAY  change  card  using  the  FPAR  field.  The  information 
displayed  is  a  detailed  transaction  dump  of  all  Main  Module  processing  of  the  aircraft  requested  on  the 
DSPLAY  card  and  all  processing  of  resources  generated  from  that  aircraft.  No  attempt  will  be  made 
to  describe  the  various  display  records  here  except  to  say  that  they  will  be  of  significant  volume  and 
will  trace  the  processing  action  throughout  all  routines  of  the  simulation  software. 
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Software  Routines  Entry/Exit 


This  report  is  for  tracing  down  the  general  location  the  software  was  processing  during  simulation 
when  an  abort  condition  ocurred.  It  aids  in  isolating  serious  problems  and  should  be  used  only  in  such 
cases  and  under  programmer  control.  It  is  activated  by  SWICH  #14.  It  produces  a  volume  of  data 
output. 

c.  Full  Transaction  Display 


This  report  is  identical  to  the  Aircraft  Transaction  Display  report  but  is  accomplished  simultaneously 
for  all  aircraft  and  non-aircraft  resources  processing.  Output  volume  is  extremely  voluminous,  for 
example,  approximately  one  inch  of  computer  paper  (full  pages)  can  easily  be  printed  for  one  huncfredth 
of  a  simulated  day  (15  minutes  of  simulation  time).  Only  the  tracing  of  severe  problems  (program  or 
data)  should  require  use  of  this  report.  It  is  activated  by  SWICH  #14. 


Stop  or  Record  Memory 


rt  -  See  Figure  9-54 


This  report  is  located  at  the  end  of  the  run  and  begins  with  the  words  "You  were  stopped..."  giving  the 
simulation  time  when  the  run  stopped.  The  data  entries  are  as  follows: 


Data  Title 


Description 


THE  ELAPSED  TIME  IN 
SECONDS  IS 

TOTAL  JOBS  STARTED 

TOTAL  JOBS  COMPLETED 


TOTAL  JOBS  PRE-EMPTED 


16.  Core  Usage  Report 


The  time  given  will  agree  with  the  CPU  time  in  the  Execution 
Report. 

Self-explanatory. 

Self-explanatory.  The  difference  between  the  started  and  completed 
jobs  will  equal  the  sum  of  the  number  in-process  and  in  backorder 
at  the  simulation  time  of  the  report. 

Number  of  jobs  that  had  one  or  more  pre-emptions  during  simulation. 


Messas 


Description 


XX  unused  words 


YY  acquired  extra  pages 


If  message  is  present,  it  will  be  located  on  the  last  page  of 
output.  It  is  an  indication  of  over-assignment  of  memory  for 
the  run.  Reduce  the  memory  assigned  by  this  value  for  optimum 
memory  utilization. 

If  message  is  present,  it  will  be  located  on  the  last  page  of 
output.  It  is  an  indication  of  under-assignment  of  memory  for 
the  run.  Increase  the  memory  limits  assigned  to  the  run  by 
this  value  (times  1000)  for  optimum  memory  utilization. 


17.  Abort  Situation  Products  -  See  Figure  9-55 

When  an  abort  condition  occurs  within  the  main  module,  the  SIMSCRIPT  U  language  provides  detailed 
diagnostic  reports  which  contains  the  following; 

1.  A  SIMSCRIPT  error  message  number  and  associated  descriptive  text. 

2.  A  trace  back  report  to  help  isolate  the  section  of  the  software  that  was  being  processed  when 
the  abort  occurred.  Specific  line  numbers,  routine  names,  and  key  data  are  printed. 

3.  Time  of  simulation  abort  is  given  as  "TIME.V  =  XX." 

4.  An  input/output  file  status  report. 

A  detailed  description  of  these  reports  can  be  found  in  SIMSCRIPT  II  user  documentation. 

Abort  recovery  is  attempted  by  LCOM  II  subsequent  to  printing  the  above  SIMSCRIPT  n  reports.  At 
this  time,  if  it  is  possible,  the  entire  initialization  is  printed  along  with  as  many  user  reports  as 
possible,  ail  of  which  will  be  "as  of"  the  time  of  the  simulation  abort.  This  printout  will  be  voluminous 
but  the  data  can  be  valuable  in  diagnosing  the  abort  situation.  When  LCOM  H  aborts,  contact 
AFMSMET  for  assistance  in  resolving  the  problem. 


V.  POST  PROCESSOR  MODULE 


A.  GENERAL  DESCRIPTION 

Diring  simulation,  it  is  possible  to  generate  a  large  amour  of  detailed  data  representing  simulation 
results.  The  data  may  then  be  combined,  summarized,  and  consolidated  into  ofrtput  reports  of  various 
kinds.  In  many  large  simulation  models,  data  generated  diring  the  simulation  are  processed  afterward 
by  a  separate  proyam  called  a  post  processor  to  obtain  the  summary  reports.  In  LCOM  II,  the 
simulation  program  itself  produces  the  main  Performance  Summary  Report  (PSR)  as  it  operates. 
However,  there  is  also  a  separate  Post  Processor  Module  that  produces  several  ancillary  products.  The 
PSR  and  other  reports  produced  during  the  simulation  reflect  the  behavior  and  status  of  the  simulated 
environment  during  discrete  time  interval  or  at  specific  points  in  time  in  accordance  with  the 
reporting  interval.  To  obtain  results  over  the  entire  simulation,  a  number  of  output  records  must  be 
inspected.  This  is  the  function  of  the  Post  Processor  Module  in  LCOM  II  -  to  develop,  within  single 
products,  selected  summary  statistics  covering  the  entire  simulation.  In  effect,  it  consolidates  the 
periodic  reports  produced  during  the  simulation.  It  also  produces  aircraft,  manpower  and  part  status 
information  as  a  function  of  simulated  time  rather  than  at  specific  points  in  time  as  output  diring  the 
simulation. 


More  specifically,  the  Post  Processor  Module  produces  seven  kinds  of  output  report  showing  simulation 
results  as  finctions  of  simulation  time.  These  products  are  displayed  in  either  graphical  or  tabular 
form  by  the  various  portions  of  the  Post  Processor  Module.  The  products  displayed  are  as  follows: 


Product 


Produced  By 


PSR  statistic  graphs  (results  vs  time) 

Aircraft  time  line  displays 

Manpower  matrices  (requirements  vs  time  of  day) 
Analysis  of  parts  usage/availability 
Mission  statistical  summary  analysis 
Realized  Flying  Schedule  (RFS)  data 
Support  equipment  usage  data 


GRAPH  Post  Processor 
DISPLAY  Post  Processor 
MATRIX  Post  Processor 
PARTS  Post  Processor 
MISSION  Post  Processor 
Transaction  DECODER 
Support  Equipment  Post  Processor 


The  Transaction  DECODER  program  provides  the  interface  between  the  Main  Module  and  the  post 
processors.  It  performs  the  functions  of  interrogation,  separating,  and  reformatting  the  data. 
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FIGURE  5-5.  DISPLAY  POST  PROCESSOR  SAMPLE  OUTPUT  (CONT'D) 


1 


HODUctxvt  uruiUrioK  nutiix  toi  ieiooicb  ciltci 


FIGURE  5-6.  MATRIX  POST  PROCESSOR  SAMPLE  IN-PROCESS  OUTPUT 


FIGURE  5-9.  PARTS  POST  PROCESSOR  SAMPLE  OUTPUT 
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TABLE  5-2.  CHRONOLOGICAL  SORTIE  HISTORY  REPORT  DESCRIPTION 
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TABLE  5-3.  MISSION  SUCCESS  STATISTICS  REPORT  DESCRIPTION 
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Data  Activation/Generation: 


SOURCE  ID  IP  ON  •EQUIPMENT 


FIGURE  5-13.  SUPPORT  EQUIPMENT  ACTUAL  GRAPH 


E. 


REALIZED  FLYING  SCHEDULE  (RFS)  DATA 


The  Realized  Flying  Schedule  data  is  used  by  the  mission  post  processor  and  several  additional 
programs  not  currently  included  in  the  LCOM  II  simulation  software.  However,  since  these  projyams 
exist  and  the  RFS  data  is  used  for  debug  purposes,  the  data  structure  itself  will  be  described  and  no 
attempt  will  be  made  to  describe  the  additional  programs.  The  Realized  Flying  ScheduIe(RFS)  data 
includes  weather  delay,  weather  cancel,  attrition,  air  abort,  sympathetic  air  abort,  RAM  and  alert 
replenishment  problem  codes. 

1.  Data  Activation  Generation 

To  cause  the  data  to  be  generated  on  the  post  processor  file,  the  data  must  first  be  requested  in  the 
Main  Module  Change  Card  file  by  using  the  SWICH  (9)  change  card.  See  Chapter  VII,  Change  Card 
Specifications,  for  card  format  and  parameters. 

Subsequent  to  the  Main  Module  run,  which  places  all  the  post  processor  data  on  a  single  file,  the 
Transaction  Decoder  program  will  place  the  RFS  data  on  a  separate  file  if  the  RFS  or  RFSP  Spec  card 
option  is  used. 

2.  General  Description 

The  actual  RFS  data  will  be  described  since  it  is  used  for  debug  purposes.  A  sample  of  the  data  is 
fotxid  in  Figure  5-9.  This  is  a  sample  only  and  is  not  described  in  this  write-up.  However,  RFS  data 
generation,  data  interpretation,  and  analysis  information  is  provided  as  follows: 

Realized  Flying  Schedule  Statistic  Implementation 

This  is  an  explanation  of  the  RFS  file  provided  by  LCOM  II  only.  The  Realized  Flying  Schedule  (RFS) 
file  is  used  as  a  debug  aid  and  is  used  as  input  data  to  the  TACFLIER  model  for  crew  ratio  studies  and 
several  other  programs.  The  RFS  output  captures  the  results  of  every  sortie  requested  in  the 
simulation  while  SWICH  9  was  turned  on.  The  data  is  presented  in  the  form  of  RFS  Records  and 
Aircraft  Records.  The  RFS  Record  types  are  described  in  Table  5-5. 


r 

TABLE  5-5  RFS  RECORD  TYPES 

A 

Record  Type 

Description 

11 

"plugged"  aircraft 

1? 

Mission/ Activity  Requests 

13 

Completion  Record  -  Flew 

10 

Completion  -  Cancelled 

K 

15 

Run  Number 

J 

The  type  12  Mission/Activity  Request  RFS  records  are  the  first  records  in  a  logical  chain  of  events 
during  the  simulation.  They  are  interspersed  throughout  the  RFS  file.  One  of  these  records  is 
produced  each  time  a  new  mission  is  requested  (scheduled  to  begin  processing-fragged)  or  when  an 
Activity  (non-mission  processing)  of  an  aircraft  is  requested  (scheduled  to  begin  processing).  The  data 
information  and  format  on  these  type  12  records  are  described  in  Table  5-5. 


TABLE  5-6  MISSION  REQUEST  RFS  RECORDS 


FORMAT 


DATA 


blank 

'12' 

blank 

current  (frag)  time 

total  aircraft  to  process  (max  &  spare) 
blank 

Max  aircraft 

weather  delay  time  On  minutes) 
minimum  aircraft  to  satisfy  mission 
blank 
mission  ID 


5-11 

12-17 

18-19 

20-27 

28-30 

31-33 

34-35 

36-43 


Immediately  af  ter  each  Mission/Activity  Request,  RFS  record  (type  12)  an  individual  aircraft  record  is 
listed  for  each  aircraft,  including  spares  required  to  satisfy  the  mission.  These  records  are  listed  by  an 
index  value  in  numerical  order.  This  index  number  is  sequential  throughout  the  simulation  and  is  an  aid 
in  locating  (verifying)  additional  RFS  information  about  the  specific  aircraft.  Aircraft  records  data 
entries  and  format  are  described  in  Table  5-7. 


TABLE  5-7  AIRCRAFT  RECORD  FORMAT 


DATA 


FORMAT 


1-6 

7-9 

10-17 

18-20 

21-26 

27-32 

33-39 

40-46 

47-53 

54-57 

58 


index  value 
blank 

request  (dummy)  tail  no 
blank 

mission  name  (from  EXOG  file) 
blank 

scheduled  take-off  time 
cancel  time  (delta) 
sortie  length 
blank 

flag  (0=aircraft  assigned  at  frag  time;  1=A/C  not 
assigned  at  frag  time 
processing  code 


12  see  footnotes 


Notes: 

1.  Mission  aircraft  processing  codes;  0  =  normal  mission  processing,  1  =  weather  delays. 

2.  Activity  aircraft  processing  codes;  2  =  weather  cancelled  mission  (treated  as  an  activity), 
3  =  alert  replenishment,  4  =  normal  activity  processing. 


Type  13  and  14  Completion  RFS  records  are  interspersed  throughout  the  RFS  file.  They  indicate  the 
status  of  the  aircraft  at  either  actual  take-off  time  (type  13  RFS  record)  or  cancel  time  (type  14  RFS 
record).  Thus,  the  type  13  RFS  record  indicates  the  aircraft  flew  and  the  type  14  record  indicates  it 
did  not  fly  or  was  a  spare.  Those  RFS  (type  12)  records  representing  an  A/C  activity  will  not  have  any 
type  13  or  14  record  in  the  data.  Weather  cancels  for  example  are  input  as  an  activity  even  though 
they  can  be  considered  a  sortie  that  cancels.  Both  the  type  13  and  14  record  have  the  same  format. 
The  data  and  record  format  is  shown  in  Table  5-8. 


TABLE  5-8  COMPLETION  RFS  RECORDS  (13s  and  14s) 

COL 

DATA 

FORMAT 

1 

blank 

2-3 

'1 3'  or  '1 4’  (RFS  Record  type) 

12 

4 

blank 

5-11 

take-off  or  cancel  time 

XXX, XXX  (D7 , 3) 

12-17 

index  value  (corresponds  to  col  1-6  of  aircraft  record) 

16  see  footnotes 

18-19 

blank 

20-27 

tail  number  (real  or  dummy) 

18 

28-30 

problem  code 

13 

31-35 

blank 

36-43 

mission  ID  (Col  36-43  of  Mission  Request  Record) 

18  see  footnotes 

Notes: 

The  mission  ID,  Col  34-39,  and  the  index  value,  Col  12-17,  make  correlation  of  this  completion 
record  with  the  originating  mission  RFS  record  (type  12)  and  its  subsequent  records. 


At  cancel  time,  if  sufficient  cocked  aircraft  can  be  directly  assigned  to  a  mission  to  permit  its  accom-- 
plishment  (bring  the  number  of  ready  aircraft  up  to  the  minimum),  sufficient  replacement  actions! 
occir.  Each  replacement  is  effectively  an  overschedule  and  the  aircraft  is  said  to  be  "plugged"  into! 
the  mission.  In  this  case  a  type  11  RFS  Record  is  produced  with  no  problem  code  specified.  Also,  on' 
this  record,  Col  12-17  will  contain  the  next  sequential  aircraft  request  index.  The  data  and  format  of 
the  type  11  RFS  Record  is  the  same  as  the  type  13  and  14  records  except  for  the  problem  code  being 
left  blank.  6 

Immediately  following  the  type  11  RFS  Record  will  be  a  type  14  RFS  Record  with  the  index  value  and 
problem  code  of  the  aircraft  or  aircraft  request  being  replaced  by  the  plugged  aircraft.  Later  in  the 
RFS  data  file  (at  take-off  or  cancel  time)  a  type  13  or  type  14  RFS  Record  will  appear  with  the 
appropriate  problem  code  and  the  new  aircraft  request  index  of  the  type  11  RFS  Record. 


Problem  codes  listed  in  columns  26-28  of  the  Completion  Records  are  defined  in  Table  5-9. 

TABLE  5-9  RFS  PROBLEM  CODES 

Problem  Code 

Problem  Description 

Applicable  Record  Type 

0 

no  problem 

13 

1 

attrition 

13 

2 

does  not  exist 

N/A 

3 

RAM 

13 

4 

air  abort 

13 

-4 

sympathetic  air  abort 

13 

5 

does  not  exist 

N/A 

6 

does  not  exist 

N/A 

7 

ground  abort 

14 

8 

maintenance  non-delivery 

14 

9 

sympathetic  ground  abort 

14 

10 

spare  aircraft  not  used 

13 

11 

FCF 

13 

5-29 


In  summary,  at  frag  time  mission  request  records  for  all  mission  and  aircraft  activities  are  produced. 
On  the  following  aircraft  Request  Records,  processing  codes  0, 1,2,3  or  4  will  be  listed  as  appropriate 
and  the  completion  records  will  indicate  the  applicable  problem  code. 

Finally,  the  decoder  program  which  actually  creates  the  RFS  file  from  output  generated  by  the  main 
module  produces  a  '15'  card  type  at  the  beginning  of  the  RFS  data  file  followed  by  a  record  which  gives 
the  run  name. 

3.  Model  Operation/Interface  with  RFS  Outputs 


As  an  additional  aid  to  experienced  users  for  debug  purposes,  the  following  detailed  model  operation 
interfaces  with  the  RFS  outputs  is  provided.  If  the  mission  is  to  fly,  '13'  records  will  be  produced  with 
a  problem  code  of  'O'  assigned.  If  the  aircraft  is  a  spare,  a  problem  code  of  '10'  will  be  assigned.  If  the 
aircraft  flying  the  mission  is  to  attrit,  go  to  RAM,  or  air  abort,  the  0  problem  code  is  replaced  by 
codes  1,  3,  and  4  respectively.  Sympathetic  air  aborts  are  assigned  the  problem  code  ’-4'.  Whenever  a 
FCF  task  is  accomplished,  a  13  RFS  Record  with  all  problem  code  is  produced.  The  weather  delay 
record  will  have  a  completion  record  just  like  the  normal  mission  processing  with  the  appropriate 
problem  codes  (0,  10,  7,  8,  9,  etc).  If  an  aircraft  assigned  to  a  cancelled  mission  had  a  status  flag  of 
40,  then  the  aircraft  was  ready  to  fly.  Therefore,  it  is  a  sympathetic  ground  abort  and  the  problem 
code  produced  is  a  '9'.  Note  that  aircraft  assigned  to  a  cancelled  mission  cannot  have  a  60  status  flag. 
Only  aircraft  that  fly  have  that  code.  If  the  aircraft  was  never  assigned  (status  flag  of  0),  then  the  tail 
no.  (Col  20-25)  on  the  completion  record  is  a  dummy  request  tail  no.  and  the  problem  code  (Col  26-28) 
will  be  an  "8".  If  the  aircraft  was  assigned  but  did  not  reach  the  sortie  task  (status  flag  of  100,  101  or 
400),  then  it  is  considered  a  g-ound  abort  and  is  assigned  a  problem  code  of  7'.  A  summary  of  aircraft 
Flags  and  the  corresponding  problem  codes  are  shown  in  Table  5-10. 


TABLE  5-10  AIRCRAFT  STATUS  FLAG/PROBLEM  CODE  RELATIONSHIP 


A/C  Status  Flag 


Problem  Code 


Applicable  Completion  Reoord 


VI.  PROGRAM  SPECIFICATION  (SPEC)  CARDS 


A.  SPEC  CARD  REQUIREMENT 


Each  SIMSCRIPT  11  Module  in  the  LCOM  II  Simulation  Software  utilizes  the  same  overall  design  for 
input  of  user  options.  A  single  card  or  record  called  the  SPEC  (specification)  card  is  utilized  for  this 
purpose  and  must  be  included  as  the  first  data  record  input  (on  I*,  05,  or  Card  Reader). 

Basic  user  options  can  be  established  through  use  of  this  SPEC  card.  The  input  of  each  option  is  free 
form,  that  is,  the  option  can  be  placed  anywhere  on  the  card,  in  any  order,  but  at  least  one  blank 
character  must  separate  any  two  options.  Only  72  characters  of  the  SPEC  record  are  used  and  should 
be  of  sufficient  length  to  contain  all  required  user  options.  No  additional  SPEC  card  is  permitted, 
however,  the  Matrix  Post  Processor,  the  Mission  Post  Processor,  and  the  Decoder  allows  continuation 
cards  to  be  used. 


The  general  form  of  the  SPEC  card  has  the  word  SPEC  on  it  first,  starting  in  any  column  (column  1  is 
preferable  only  to  provide  maximum  space  on  the  card  for  options).  Subsequent  entries  (options)  are  of 
the  form  xxxx=yy.  Although  spaces  are  permitted  around  the  =  sign,  elimination  of  them  is  also 
preferable  for  space  utilization. 


B.  FILE  ASSIGNMENT  REQUIREMENTS 


Where  the  option  specifies  a  unit  nn  which  has  a  default  value,  a  file  must  be  assigned  in  the  Job 
Control  Cards  (either  the  default  or  the  unit  specified).  Where  the  option  specifies  a  unit  nn  and  the 
default  is  undefined,  only  the  unit  nn  need  be  assigned  in  the  control  cards  when  the  option  and  unit  are 
specified  by  the  user. 


For  all  programs,  the  unit  specified  can  be  any  number  from  J  thru  15  (Honeywell  only)  with  5  reserved 
as  the  card  reader  (I*  or  05  file),  and  6  the  printer  or  print  file.  For  both  the  Input  and  Main  modules 
(Honeywell  version  only),  file  //1 5  is  reserved  as  an  optional  print  file. 


C.  SPEC  CARD  DESCRIPTIONS 


The  SPEC  card  for  each  program  and  the  various  options  permitted  are  described  as  follows:  (Tables 
6-1  thru  6-11). 


TABLE  6-1.  INPUT  MODULE  SPEC  CARD 


OPTION 


FORM=nn 


PRNT=1 5 


EXOG=nn 


INIT=nn 


INFO=n 


DESCRIPTION 


DEFAULT 


Required  as  first  entry. 


User  forms  are  input  on  init  nn.  5 

Processing  and  editing  reports  are  output  to  unit  15.  See  Note.  6 

Exogenous  data  (flying  program)  is  output  to  unit  nn  in  BCD.  0 

Initialization  data  is  output  to  unit  nn  in  binary.  7 

Information  flag  relating  to  debug  of  data;  0 

0  =  partial  node  table  (only  nodes  with  error  codes) 

1  =  above  plus  resource,  task,  failure  clock,  and  control  table  dictionaries 

2  =  all  above  plus  class  table  and  search  pattern  table  dictionaries 

3  =  all  above  plus  the  complete  node  table 

4  =  all  above  plus  a  print  of  the  initialization  data 


NOTE:  On  the  Honeywell  implementation,  unit  15  is  the  alternate  print  file  reserved  for  the  PRNT 

option  and  should  not  be  used  as  the  nn  file  for  the  other  options.  Also  use  nc  system  FFILE  cards  with 
J  \this  unit.  This  is  due  to  the  Input  Module  objects  being  maintained  in  absolute  (Hjf)  Form.  J 


OPTION 

SPEC 

CHNG=nn 

PRNT=nn 


INIT=nn 


EXOG=nn 


DUMP=nn 

POST=nn 


DATA=nn 


TABLE  6-2.  MAIN  MODULE  SPEC  CARD 


DESCRIPTION 


Required  as  first  entry. 


Change  cards  are  input  on  unit  nn  in  BCD. 

Processing  reports  are  output  on  unit  nn. 

Initialization  data  is  input  on  unit  nn  in  binary. 

Exogenous  Data  (flying  program)  is  input  on  unit  in  BCD. 

Memory  dumps  are  output  to  unit  nn. 

All  post  processor  outputs  are  sent  to  unit  nn  in  binary.  The  pro¬ 
gram  does  not  automatically  rewind  this  file. 

The  standard  print-out  of  the  initialization  data  will  be  directed  to 
unit  nn.  Being  a  print  file  no  system  FFILE  card  is  used. 


DEFAULT 


NOTE:  *  No  default  exists  for  this  option.  If  memory  dumps  are  desired,  the  option  and  unir  must  be 
entered,  and  the  unit  assiyied  in  the  JCL.  Device  must  be  a  tape.  Option  is  invalid  on  the  ODC  and 
ITEL  (IBM  compatable)  computers. 

**On  the  Honeywell  implementation,  Unit  15  is  the  alternate  print  file  reserved  for  the  DATA 
option  and  should  not  be  used  as  the  nn  file  for  the  other  options.  Also,  use  no  system  FFILE  cards 
Njdth  this  unit.  This  note  applies  only  when  using  the  MAIN  module  objects  in  an  absolute  (Hit)  Form. 

— '7 — n  -  ■■■  - ■■■-  - - -  ——i 


TABLE  6-3.  RESTART  MODULE  SPEC  CARD 


DEFAULT 


OPTION 


Required  as  first  entry. 

Restore  memory  dump  tape  is  on  unit  nn. 

Checkpoint  //nn  is  to  be  read  prior  to  restarting  simulation 


CHEK=nn 


TABLE  6-4.  DECODER  SPEC  CARD 


DEFAULT 


DESCRIPTION 


OPTION 


Required  as  the  first  entry. 

Graph  data  in  binary  is  to  be  output  on  unit  nn.  See  GRPD. 

Graph  data  in  binary  is  to  be  output  on  unit  nn  and  a  dictionary  of 
STAT  titles  is  produced. 

Display  data  in  binary  is  to  be  output  on  unit  nn. 

RFS  (Realized  Flying  Schedule)  data  in  BCD  is  to  be  output  on  unit 
nn.  See  RFSP. 


GRPH=nn 


GRPD-nn 


DPLYmn 


RFSP=nn  RFS  data  in  BCD  is  to  be  output  on  unit  nn  and  a  listing  of  the  ** 

data  is  produced.  Print-out  is  usually  voluminous. 

SEQ=nn  Support  Equipment  data  in  BCD  is  to  be  output  on  unit  nn.  See  ** 

SEQP. 

SEQP=nn  Support  Equipment  data  in  BCD  is  to  be  output  on  unit  nn  and  a  ** 

listing  of  the  data  is  produced.  Printout  is  usually  voluminous 

PRTS=nn  Parts  dictionary  data  (in  binary)  is  to  be  outpu1  on  unit  nn.  ** 

PBCD=nn  Parts  BCD  data  is  to  be  output  on  unit  nn.  (Not  sorted)  1 4*** 

MTRX=nn  Matrix  dictionary  data  (in  binary)  is  to  be  output  or.  unit  nn.  ** 

MBCD=nn  Matrix  BCD  data  is  to  be  output  on  unit  nn.  (Not  sorted)  15#*# 

[N  =nn  Post  Processor  data  in  binary  from  SIMRUN  is  input  on  unit  nn.  1 

DBUG=n  Additional  debug  output  messages  are  produced,  value  may  be  1,  2,  0 

3  or  4,  where  the  higher  numbers  produce  the  most  output. 

NOTES:  *Up  to  two  card  can  be  used  to  hold  the  Decoder  SPEC  options.  The  first  card  only  must 

start  with  the  word  SPEC  and  the  last  card  must  end  with  a  blank  followed  by  an  asterisk  (*). 
Therefore,  when  only  one  SPEC  card  is  used,  it  must  also  end  with  the  blank  followed  by  an  asterisk 


**No  defaults  exist  for  this  option.  If  a  particular  output  is  desired,  the  option  and  init 
must  be  entered  and  assigned. 

***These  defaults  are  only  effective  when  the  corresponding  dictionaries  are  requested. 


OPTION 


IN=nn 

DBUG=n 


DAYS=nn 


FDAY=nn 


STAT=nn 


STRT=nnn 


STOP=nnn 


TABLE  6-7.  GRAPH  POSY  PROCESSOR  SPEC  CARD 


DESCRIPTION 


DEFAULT 


'  Required  as  first  entry. 


Input  data  in  binary  is  on  unit  nn. 

Additional  debug  output  messages  are  produced.  Value  may  be  1, 
2,  3  or  4,  with  4  providing  the  most  output  and  includes  all 
the  oata  point  values. 

Necessary  if  graphs  of  statistics  are  desired,  number  to  input  is 
determined  by  DECODER. 

Necessary  if  forecasted  data  is  to  be  graphed,  r  umber  to  input 
is  determined  by  DECODER. 

Required  to  get  any  statistics  graphs,  must  be  the  number  of 
graphs  wanted,  maximum  value  can  be  found  as  the  last  entry  in 
the  STAT  dictionary  produced  by  the  DECODER  with  GRPD  option. 
See  Notes  *  and  **. 

The  earliest  day  or  starting  location  of  the  x-axis  on  the  graphs. 
See  Note  ***. 

The  latest  day  or  ending  loca  ion  of  the  x-axis  on  the  graphs.  See 
Note  ****. 


NOTES:  *  Without  any  option  specified  only  the  histogram  of  the  aircraft  post-sortie  turnaround 

time  is  provided  by  this  graph  run.  This  histogram  is  provided  >n  all  graph  runs. 

**  If  fewer  than  the  maximum  number  of  statistics  are  requested,  the  specific  dictionary 
numbers  of  those  statistics  wanted  must  be  inpjt  on  one  or  more  cards  immediately  following  the 
SPEC  card.  These  dictionary  numbers  must  be  obtained  from  the  DECODER  run  with  the  GRPD 
option.  These  numbers  are  entered  on  the  cards  in  a  free  torn:  manner  (separated  by  at  least  one  blank 
field),  and  may  use  as  many  cards  as  necessary  to  input  all  the  required  STAT  numbers.  The  last  value 
must  be  followed  by  a  blank  field  and  an  asterisk.  For  example,  if  only  STAT  #6  and  9  are  wanted,  the 
SPEC  CARD  option  will  be:  ”STAT=2"  and  the  following  card  would  be:  "6  9  *",  When  all  statistics 
are  wanted  and  if  the  maximum  =  73,  the  SPEC  ca»-d  option  would  be:  "STAT  =  73"  and  no  following 
card  would  be  used. 

***  If  the  STRT  day  is  not  a  day  a  PSR  is  obtained  then  the  starting  location  will  be  set  to 
the  next  PSR  day  which  is  greater  than  the  STRT  day.  The  STRT  day  must  be  less  than  the  STOP  day. 

****  If  the  STOP  day  is  not  a  day  a  PSR  is  obtained  then  the  ending  location  will  be  set  to  the 
closest  PSR  day  which  is  less  than  the  STOP  day.  The  STOP  day  must  be  greater  than  the  STRT  day. 


TABLE  6-8.  MATRIX  POST  PROCESSOR  SPEC  CARD 


DESCRIPTION 


DEFAULT 


OPTION 


Required  as  first  entry. 

BCD  input  unit  is  on  nn  (from  sort). 

Dictionary  input  is  on  unit  nn.  (MTRX  output  of  Decoder). 

Additional  debug  output  messages  are  produced.  Value  may  be 
1-4,  with  4  producing  the  most  volume. 


DICT=nn 


DBUG=n 


Required;  number  of  work  centers  for  which  matrices  are 
requested.  See  Note  ***. 

Starting  day  of  matrices.  See  Note  »***. 

Required;  stopping  day  of  matrices. 


STRT=nn 


STOP=nnn 


Number  of  blocks  matrices  are  to  be  broken  up  into.  For 
instance,  if  weekdays  are  to  be  computed  separately  from 
week-ends,  NBLK =2,  BLKI=5,  BLK2:2.  NBLK  may  be  1,  2,  or  3 


NBLK=n 


Number  of  days  in  block  1.  Required  if  NBLK  is  greater  than 
1,  else  defaults  to  entire  matrix  length. 


Number  of  days  in  block  2.  Reiuired  if  NBLK  is  greater 
than  1. 


BLK2=nn 


Number  of  days  in  block  3.  Required  if  NBLK=3 


BLK3=nn 


NOTES:  *  Up  to  two  cards  can  be  used  to  hold  the  Matrix  SPEC  options.  The  first  card  must  be  the 

only  card  that  starts  with  the  woid  SPEC  and  the  last  card  must  end  with  a  blank  followed  by  an 
asterisk  (*).  Therefore,  when  only  one  SPEC  card  is  used,  it  must  also  end  with  the  blank  followed  by 
an  asterisk  (*). 


**  There  normally  is  no  default  fa  these  entries.  If  the  entry  must  be  made  and  is  not,  the 
run  will  stop  with  an  appropriate  diagnostic  message. 

***  Because  each  block  of  each  work  center  could  have  different  shifts,  NUM  times  NBLK 
work  center  cards  must  follow  tiie  SPEC  cards. 


**»*  No  matter  what  day  you  want  to  see  matrices  start  being  produced,  the  matrix  program 
assumes  day  1  of  block  1  starts  at  day  0.0.  Fa  example,  if  you  are  using  NBLK=2,  BLKU5,  BLK2=2, 
STRTdO,  the  matrix  program  computes  that  the  data  ycu  want  to  see  really  starts  with  the  4th  day  in 
the  second  occurrence  of  block  1  data.  . 


TABLE  6-9.  WORK  CENTER  DATA  CARDS 


Justification 


Column 


Information 


AAAAAA 


Work  Center  Name 
Block  Number 
%  of  Indirect  Labor 
Number  of  Shifts  (Max=8) 
Start  Time  of  Shift  I 

Start  Time  of  Shift  2 

Start  Time  of  Shift  3 

Start  Time  of  Shift  4 

Start  Time  of  Shift  5 

Start  Time  of  Shift  6 

Start  Time  of  Shift  7 

Start  Time  of  Shift  8 


NOTE:  Shift  start  times  are  in  integer  hours  (00-24),  with  the  smallest  shift  time  first.  The  first 

shift  of  ail  blocks  of  the  same  work  center  must  have  the  same  start  time.  Also,  be  sire  that  all  cards 
pertaining  to  the  same  work  center  occir  together. 
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I 

I  OPTION 
SPEC 
IN=nn 
DATA=nn 
STAT=nn 
STRT=nnn 

STOP=nnn 

LVLl=nn 

LVL2=nn 

DTIM=nnnn 

NTIM=nnnn 

ASWT=n 

NERR=nn 


NMSNrnn 


DBUG=n 


TABLE  6-10.  MISSION  POST  PROCESSOR  SPEC  CARD 

DESCRIPT/ON  DEFAULT 

Required  as  first  entry.  » 

RFS  data  in  BCD  is  on  unit  nn.  ** 

Output  unit  for  Chronological  Sortie  History.  6 

Output  unit  for  Mission  Success  Statistics.  6 

Integer  start  day  for  production  of  sortie  nistory  and  accumulation  0 

of  success  statistics. 

Integer  stop  day.  1000 

Number  of  days  between  the  basic  (Level  1)  Mission  Success  ** 

Statistics  Reports. 

Number  of  basic  Level  1  reports  between  Mission  Success  Statistics  ** 

Summary  (Level  2}  Reports. 

Use  this  option  to  change  the  beginning  of  the  time  period  used  to  0600 

calculate  Daylisht  Sorties  on  the  Level  2  and  3  Summary  Reports. 

Use  this  option  to  reset  the  ending  time  of  the  time  period  used  to  1800 

calculate  Daylight  Sorties  on  the  Level  2  and  3  Summary  Reports. 

When  the  activity  swi  tch  is  set  to  1,  no  report  is  made  against  0 

activities. 

Records  are  matched  (FRAG  and  MISSIONS  or  FRAG  and  CANCELS)  10 

diring  processing.  Depending  on  RFS  tapout,  START  and  STOP 

times,  attempting  this  match  will  result  in  bad  or  incomplete 

records.  If  mere  bad  records  or  incomplete  records  than  specified 

occur,  run  terminates  with  diagnost  cs. 

This  item  is  used  to  determine  the  size  of  the  data  arrays  for  the  50 

post  processors.  Missions  are  distinguished  by  name,  scheduled 

takeoff  time  of  day,  and  size.  If  insufficient  missions  are  allowed, 

run  terminates  with  an  appropriate  diagnostic  message.  This 

number  should  be  greater  thin  the  number  of  Form  20  data  records 

input.  Where  the  MAX=99  option  on' Form  20  was  used,  this 

quantity  should  be  increased  by  approximately  the  number  of 

aircraft  authorized.  Memory  required  to  process  this  post  processor 

with  the  default  of  50  is  20K  decimal.  Increase  memory  allocation 

by  IK  for  each  additional  value  of  25. 

When  the  debug  switch  is  set  to  1,  messages  for  programmer  0 

analysis  will  be  produced. 


NOTES:  *Up  to  two  cards  can  be  used  to  hold  the  Mission  SPEC  options.  The  first  card  must  be  the 
only  card  that  starts  with  the  word  SPEC  and  the  last  card  must  end  with  a  blank  followed  by  an 
asterisk(*).  Therefore,  when  only  one  SPEC  card  is  used,  it  must  also  end  with  the  blank  followeid  by 
an  asterisk. 

** There  is  no  default  for  these  entries.  If  not  specified,  the  run  will  stop  with  an  appropriate 
^diagnostic  message. 
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TABLE  6-11.  SUPPORT  EOUPMENT  POST  PROCESSOR  SPEC  CARD 

DESCRIPTION 


DEFAULT 


SPEC  Required  as  first  entry. 

iN=nn  Support  Equipment  data  in  BCD  is  on  unit  nn.  1 

NUM=nnn  Number  of  pieces  of  support  equipment  to  be  graphed.  * 

STRT=nnn  Integer  starting  day  for  production  of  graphs.  0 

STOP=nnn  Integer  stopping  day  for  production  of  graphs.  60 

DBUGrn  Additional  output  is  produced  depending  on  the  value  of  n  as  follows:  0 

0  -  error  messages  only 

1  -  above  plus  input  data  printed  for  desired  graphs 

2-3  -  above  plus  message  indicating  any  resource  ID's  on  file  but  not 
desired 

4  -  above  plus  task  start  and  stop  intervals,  model  and  actual 

counts  (programmer  aids) 

NOTE:  *One  or  more  cards  must  follow  SPEC  card  to  indicate  which  support  equipment  resources 

are  to  be  graphed.  The  user  inputs  the  resource  ID's  in  a  free  form  format  followed  by  an  asterisk(*). 
The  number  of  entries  must  not  exceed  the  number  in  the  NUM  option  or  the  run  is  terminated. 


Vn.  CHANGE  CARD  SPECIFICATIONS 


A.  CHANGE  CARD  PROCEDURE.  (See  Table  9-42  for  sample  CHANGE  CARD  file) 

Once  the  Input  Module  produces  an  initialization  file  for  the  Main  Module  to  process,  the  user  may  find 
it  necessary  to  make  certain  run  specifications  or  make  certain  small  variable  changes  prior  to  the 
simulation  run.  It  is  possible,  depending  on  the  variable,  to  make  these  changes  or  specif icatiohs 
during  the  Main  Module  processing  and  consequently  avoid  additional  input  processing.  CHANGE 
CARDS  have  been  defined  to  permit  this  action.  The  CHANGE  CARDS  are  included  as  a  part  of  the 
run  deck  on  the  CHANGE  file  designated  on  the  Main  Module  SPEC  card  (see  SPEC  card  write-up). 

Only  one  of  these  cards,  the  "STOP"  card,  is  always  mandatory  tc  start  the  simulation  and  indicates 
the  total  time  the  user  desires  to  simulate.  This  "STOP"  card  will  always  be  the  last  CHANGE  CARD 
in  any  set  of  CHANGE  CARDS.  Each  variable  CHANGE  CARD  should  be  used  only  once  since  the  last 
CHANGE  CARD  parameters  read  override  all  previous  ones  of  that  particular  type.  The  exception  to 
this  would  be  the  SWICH  and  Special  Request  cards  which  permit  requesting  multiple  reports  to  be 
printed  at  various  simulation  times. 

B.  SWICH  SETTING. 

An  important  variable  in  the  list  of  variables  that  can  be  changed  is  one  called  "SWICH."  Each  of 
these  switches  has  a  specific  function  to  perform  in  the  Main  Module.  Only  switches  4  and  5  are  set 
equal  to  1  automatically  by  the  input  module.  All  others  are  off  at  the  start  of  the  run.  Normally,  the 
switches  are  bimodal  where  "0"  is  off  and  "1"  is  on.  Where  additional  values  are  allowable,  they  are 
described  in  Table  7-1. 

The  variable  SWICH  is  the  only  one  of  the  change  variables  which  requires  that  two  pieces  of 
information  be  combined  to  insert  on  the  change  card  in  Columns  7-12  (IPAR).  Both  the  SWICH 
number  and  desired  setting  are  combined.  The  SWICH  NO.  is  right  justified  only  to  Column  II  and  the 
setting  is  placed  in  Column  12. 

Examples  are:  Set  SWICH  15  on  -  IPAR  =  151 

Set  SWICH  6  to  4  -  IPAR  =  64 
Set  SWICH  5  off  -  IPAR  =  50 

No  limit  is  made  as  to  how  often  a  particular  SWICH  is  set  or  the  time  when  it  is  set.  This  is  entirely 
up  to  the  user.  An  example  would  be  where  a  user  wishes  to  output  the  RFS  data  from  the  end  day  6 
through  day  10.  SWICH  #9  would  be  turned  on  at  day  6  and  off  at  day  10.  This  would  require  two 
SWICH  CHANGE  CARDS.  When  a  BOSTAT  change  card  is  used,  SWICH  #8  is  automatically  set.  It 
should  never  be  set  by  the  user  since  it  is  only  needed  in  the  collection  of  data  for  selected  reports. 

C.  NON  ’JSE  CHANGE  CARDS 

The  Forecast  and  Decision  model  implemented  in  LCOM  I  has  not  yet  been  implemented  in  LCOM  II. 
However,  their  driving  parameters  and  change  cards  are  in  the  model  for  possible  future 
implementation.  The  applicable  change  cards  described  within  the  tables,  that  should  not  be  used  are 
as  follows: 

ALFA  BATCH  OVALU  ESS  FLTR  SMCON  TINCR  TRIG 

ALPHA  BOTM  DSTAT  FLOOR  SCALE  TFCST  TRACK 

D.  CHANGE  CARD  FORMAT  AND  PARAMETER  REQUIREMENTS 

The  CHANGE  CARDS  must  be  written  in  the  prescribed  format  (see  Table  7-2)  with  no  additional 
comments  added.  The  parameters  that  are  required  for  each  change  card  are  specified  in  Table  7-3. 
The  function  of  each  change  card  and  cautions  to  be  adhered  to  are  described  in  Table  7-4. 

Edits  are  conducted  on  many  of  the  parameter  fields  and  result  in  either  warning  or  fatal  messages.  In 
most  cases  the  abort  condition  caused  by  the  fatal  message  is  deferred  until  Change  Cards  are  read. 


TABLE  7-1  SWICHes  UNDER  USER  CONTROL 


the  printing  of  detailed  programmer  diagnostics.  See  footnote  5. 

-  causes  printing  of  entries  and  exists  from  main  routines 

-  prints  above  plus  internal  routine  diagnostics  and  KT1MSW  diagnostics. 


VNAM  IPAR  FPAR  IAPAR  IPAR2  FPAR2  NOTE  12 
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This  column  indicates  the  allowable  simulation  time  the  Change  Card  can  be  used- 


TABLE  7 -4  CHANGE  CARD  VARIABLE  DESCRIPTION 


«-»  •-* 

U 

s 

^  c 

o° 

£ 

< 

c 

•■4 

■S" 

>U  (/)  rA 

H  <?.  r- 

</> 

il 

HH 

4k 

BOSTAT  Request  a  BackOrder  Status  Report  at  time  FPAR. 


7-11 


ESS  Scaling  factor  in  the  Decision  Model;  control  relative  worth  of  items. 
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selection  on  A,  E,  and  G  parameters;  #7  for  random  multiplier  for  initial  dock  settings;  #8  is  unused. 
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Specifies  the  class/configuration  //  (IPAR)  into  which  all  initially  generated  aircraft  of  the  type  specified 
(IAPAR)  are  placed  (only  the  originals).  Default  is  the  first  class  specified  on  Form  17.  Card  only  valid  at 
time  =  0.  For  those  generated  by  task  see  change  card  GENRAT. 
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UCOST  cirrent  unit  cost  of  a  specified  resource. 

WARMUP  Specified  length  of  model  warmup  period.  The  first  level  II  report  is  produced  at  end  of  warmup  period. 
Only  valid  at  time  =  0.0. 

WCXCOL  Used  to  input  weather  cancel  report  column.  Can  only  be  used  in  conjunction  with  TACMOD  card. 


VIII.  INPUT  FORMS  AND  THEIR  PREPARATION 


In  describing  the  input  forms,  Form  1 1  is  described  first  because  of  its  fundamental  inportance  in  the 
data  package.  Once  it  is  understood  many  of  the  other  related  forms  are  more  easily  understood. 
The  remaining  order  of  form  descriptions  is  also  not  in  numerical  sequence  for  similar  reasons  of 
data  clarity  and  interrelationship.  The  required  input  sequence  and  other  procedures  are  discussed  in 
Chapter  XI. 

NOTE:  In  preparing  the  input  data,  all  data  records  from  the  same  input  form  are  grouped  and  must 
be  preceded  by  a  header  record.  This  record  contains  the  form  number  in  Columns  2  and  3  with  the 
remainder  of  the  card  left  blank  or  optionally  filled  in  with  any  information  the  user  desires. 

Where  possible,  prepared  forms  used  as  figures  in  this  chapter  will  be  similar  to  those  of  the  sample 
problem  in  Chapter  IX.  However,  most  of  these  examples  will  be  different  than  the  sample  problem. 

For  the  purposes  of  clarity  and  ease  of  reference  to  the  individual  forms,  the  remainder  of  this 
chapter  will  be  typed  across  the  page  in  the  opposite  direction.  Where  possible,  the  form  will  be 
described  in  the  text  on  the  page  immediately  facing  the  referenced  form. 
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LOGISTICS  COMPOSITE  MOOEL  loom  I  -  simulation  model  inputs 

FORM  11  -  TASK  NETWORK 
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FIGURE  8-1  FORM  11  PREPARATION  EXAMPLE  -  TASK  NETWORK 
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Column  11  indicates  that  this  is  a  continuation  card  for  that  specific  task.  This  option  has  special  error  checking  capabilities  and 
ensues  that  these  successive  records  do  not  get  out  of  sequence. 

General  resource  substitution  can  be  activated  thru  the  use  of  the  "C"  columns  (43,  52,  or  61).  An  "X"  placed  in  any  of  these  fields 
indicates  that  general  substitutions  (as  specified  on  Form  13)  is  permitted.  Since  these  same  columns  are  used  for  the  consume  flag,  it 
is  impossible  to  have  both  features  operate  simultaneously  for  the  same  resource. 
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FORM  12  -  TASK  DEFINITIONS 
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Form  1*  -  Faille  Clock  D«cr 
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IGURE  8-5.  EXAMPLE  OF  AN  EMPIRICAL  DISTRIBUTION  FIGURE  8-6.  EXAMPLE  OF  AN  EMPIRICAL  DISTRIBUTION 
STEP  FUNCTION  LINEAR  INTERPOLATION 
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FIGURE  8-7.  cORM  IS  PREPARATION  EXAMPLE  -  DISTRIBUTIONS 


1.  Single  Line  Shift  Policy  Entry.  A  shift  policy  is  defined  in  terms  of  shift  durations,  shift  repetitions,  and  shift  authorizations. 
A  separate  line  on  Form  16  is  used  to  describe  each  of  these  factors.  Data  entered,  for  each  type  of  line,  is  as  follows:  Refer  to 
Figure  8-8.  The  Shift  M  echanism  is  described  in  Chapter  IV,  Section  Bll. 
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10  -  Performance  Summary  Report 
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(d)  Aircraft  ID  or  Rcsotrce  ID.  The  resource  name  of  the  aircraft  associated  with  the  mission  or  activity,  or  the  non¬ 
aircraft  resource  associated  with  the  activities  placed  here.  This  must  correspond  exactly  to  the  resource  name  on  Form  13.  Where 
non-aircraft  resources  are  specified,  Form  13's  column  1 1  must  contain  an  asterisk.  A  blank  field  will  cause  the  dummy  (non- aircraft) 
resovrce  to  be  used.  The  dummy  resource  is  automatically  defined  and  is  the  last  one  m  the  resource  dictionary. 


FIGURE  8-11.  FORM  20  PREPARATION  EXAMPLE  -  SORTIE  GENERATION  DATA 
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A  dose  support  mission  (CLSPT)  will  also  be  fragged  each  day  for  the  next  999  days  (actually  60  since  only  60  days  are  generated). 
The  number  of  such  missions  for  each  day  is  determined  by  a  draw  from  distribution  //2,  the  take-off  time  for  each  mission  obtained 
from  distribution  #3,  and  the  mission  length  is  obtained  from  distribution  //l.  There  is  no  advance  warning  for  this  mission;  the 
aircraft  have  1 5  minutes  to  get  off  the  ground.  Next,  seven  training  missions  (TNG)  are  to  be  flown  each  day  at  the  scheduled  times, 
starting  on  day  5  and  continuing  until  day  10.  Finally,  on  day  7  a  TEST  activity  is  to  be  processed  a.  0400  for  10  aircraft. 


Both  Missions  and  Activities  are  defined  on  the  Form  17,  but  they  are  described  separately  below.  They  are  both  processed  within  a 
single  group  of  Form  17s  and  require  the  normal  Header  Record.  Mission  and  Activity  names  are  mentioned  on  Input  Form  20  -Sortie 
Generation  Data  (refer  to  Chapter  VIII,  Section  3  of  this  chapter).  On  Form  17  -  Mission  Entry  Points,  each  mission  name  is  unique  and 
is  associated  with  a  particular  entry  node  in  the  task  network.  This  entry  node  identifies  the  first  in  a  sequence  of  tasks  which  must  be 
accomplished  to  satisfy  the  mission  or  activity  requirement.  The  data  element  entries  are  as  follows:  See  Figure  8-12. 


(b)  Report  Column.  Activities  as  a  new  LCOM  II  feature  have  been  defined  but  no  data  is  collected  on  the  main 
Performance  Summary  Report  (PSR).  Therefore,  this  Report  column  has  been  deactivated.  In  the  interim,  this  column  is  used  to 
define  the  type  of  resource  the  activity  applies  to.  For  aircraft,  insert  the  two  characters  "AC"  in  these  columns.  This  will  cause  the 
input  model  to  read  and  edit  the  remaining  data  from  Columns  22-48.  For  non-  air  craft,  enter  the  two  characters  "OT."  This  causes 
data  in  Columns  22-48  to  be  ignored. 


LOGISTICS  COMPOSITE  MODEL  lcom  ii  -simulation  model  inputs 

FORM  21  •  AIRCRAFT  ASSIGNMENT  SEARCH  PATTERNS 
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FIGURE  8-15.  FORM  23  PREPARATION  EXAMPLE -INX  EQP .  GROUP.  DEF . 


IX.  SAMPLE  PROBLEM  3.3 

The  problem  described  in  this  chapter  is  a  complete  sample  package  including  the  network  drawings, 
completed  applicable  forms  filled  in,  input  processing  results,  and  sixty  day  simulation  run  exercising 
many  of  the  run  options.  Post  processor  results  lased  upon  this  simulation  are  presented  in  Chapter 
V  and  include  sample  output  products  from  each  of  the  post  processors.  Sample  problem  #3.5  was 
developed  as  an  update  to  sample  problems  (#1,  2,  and  3)  previously  described  in  LCOM  I  and  LCOM 
II  user  documentation.  With  only  minor  changes  to  these  previous  sample  problems,  many  of  the  new 
features  including  configuration  management  are  being  exercised. 


The  purposes  for  including  sample  froblem  #3.5  in  this  users  guide  are: 

1.  To  provide  guidance  in  the  development  of  any  data  package  and  in  the  use  of  many  of  the 
features  and  options. 

2.  To  provide  a  complete  package  as  a  tool  for  implementation  of  the  LCOM  II  simulation 
software  on  another  computer  system. 

3.  To  provide  a  set  of  examples  of  completed  forms,  opt  on  use,  reports  available  and  their 
format. 


B.  General  Description 

This  problem  describes  the  use  and  repair  of  l  particular  aircraft.  It  contains  a  fairly  thorough 
description  of  its  operations  in  terms  of  a  network  of  flight  line  tasks.  It  describes  the  aircraft 
maintenance  network  in  detail  only  on  two  of  the  aircraft  systems,  where  one,  the  hydraulics,  is 
maintained  to  the  first  indenture  and  the  othei ,  the  communications,  is  maintained  to  the  second 
indenture. 

The  hydraulic  system  has  two  subsystems,  HI  and  H2,  which  are  removed  and  replaced  on  the 
aircraft  and  subsequently  repaired  or  sent  to  depot  for  replacement. 

The  communications  system  has  only  one  subsystem.  Cl,  which  is  removed  and  replaced  on  the 
aircraft.  Subsystem  Cl's  repair  consists  of  removing  and  replacing  one  er  both  of  its  major 
assemblies,  Cl  1  and  Cl 2,  which  are  subsequently  repaired  or  sent  to  depot  for  replacement. 

This  problem  is  primarily  an  enhanced  version  of  the  examnle  problem  used  in  the  RAND 
Memorandum  RM-5544-PR  describing  LCOM.  This  example  is  Figure  2  on  page  13  of  that 
publication. 

Another  interesting  note  is  that  basically  this  is  the  test  pad-ige  originally  developed  to  aid  in  the 
testing  and  debugging  of  the  original  LCOM  during  its  development  effort.  Only  minor  changes  have 
been  made  to  selectively  test  newer  options.  This  is  important  to  those  users  implementing  the 
model  on  a  different  computer.  Approximately  90  percent  of  all  code  is  processed  by  this  sample 
problem.  This  problem  is  constantly  being  used  as  a  test  case  for  checking  out  additional 
modifications  to  LCOM  II.  To  enhance  testing  a  second,  but  similar,  aircraft  has  been  added.  It 
processes  one  of  the  Pre-sortie  networks  and  the  same  Post-sortie  network  used  by  the  original 
aircraft. 


The  following  provides  a  summary  of  the  LCOM  II  features  >jsed  and  not  used  within  this  sample 
problem.  Of  the  features  used,  many  of  them  will  be  discussed  within  the  next  sub-section,  Problem 
Development. 


Features  Used 
Activities  for  aircraft 
Network  selection  modes 
A,C,D,E,F,H,I,J,K,R,S  &  T 
Generating  non-aircraft  resources 
Consuming  non- aircraft  resources 
Failure  mechanism 
Halt  mechanism 
Shift  mechanism 
Tail  number  tracking 
Configuration  Management  both  internal 
and  external 

Priority  system  (Defaults) 

Aircraft  timing  switch 
Attrition 
RAM  repair 

Initial  aircraft  assignment  change 
Warmup 

Time  Controlled  activltlty  processing 
Aircraft  tracking 
Use  of  Empirical  Distributions 
Multiple  aircraft 
General  resource  substitution 
Task  Specific  resoirce  substitution 
Task  substitution  on  a  daily  basis 
Spare  Aircraft  assignment  control 
Expanded  Node  Usage  Report 

D.  Problem  Development 

In  this  chapter,  the  figures  and  tables  are  explicitly  ordered  for  the  purpose  of  sequentially 
representing  the  completed  forms  as  they  would  be  submitted  and  tie  output  products  as  they  would 
be  produced.  References  to  these  are  often  not  in  a  similar  sequence  but  better  represent  data 
development  sequence 

1.  Data  Plot 

Once  the  problem  was  defined,  the  first  and  most  iogica*  step  was  to  draw  the  network  in  detail 
Including  the  necessary  task  data.  Figure  9-1  is  a  computerized  plot  of  the  complete  Sample 
Problem's  network.  It  is  divided  in  five  parts  which  a,-e: 

a.  Part  1  -  Entry  point/flight  line  network: 

b.  Part  2  -  Call  Sections  networks 

c.  Part  3  -  Unscheduled  maintenance  network 

d.  Part  9  -  Internal  Equipment/Repair  and  Reconfiguration  networks. 

e.  Part  5  -  External  Reconfiguration  networks. 

This  plot  provides  a  sire  method  of  visual  audit  of  the  networks  and  enables  the  modification  of 
erroneous  data.  From  these  networks,  as  dtawn,  Form  II  and  part  of  Form  12  could  be  filled  out 
directly.  Reference  Figures  9-3  and  9-9  respectively.  The  following  are  further  comments  about 
each  form./ 


Featires  Not  Used 
P$R  oartitionlng 
Network  selection  modes 
B  and  G 

Generating  aircraft  resources 
Consuming  aircraft  resources 
Multiple  Hit  Matrices 
Air  aborts 

Task  substitution  on  s  calender  basis 

TACMOD 

SECIN  scheduled 

FACTOR 

Dump  &  Restart 

Air  Abort  Control 


2.  Form  10  -  Report  Specifications.  Reference  Figure  9-2.  After  making  a  general 
description,  the  operations  environment  (flying  program)  cards  subtype  3  and  5  were  completed. 
Information  on  cards  subtype  7,  9  and  1 1  came  from  a  review  of  the  networks  and  the  general  format 
of  the  Performance  Summary  Report  desired.  Since  this  problem  is  small,  we  needed  less  than  10 
columns  in  any  of  the  report  sections,  but  we  could  have  easily  required  more  had  the  problem  size 
demanded  it. 

3.  Form  1 1  -  Task  Networks.  Reference  Figure  9-5.  The  network  as  defined  in  Figure  9-1  was 
placed  on  this  form.  A  general  network  naming  convention  was  followed.  All  mission  pre-sortie 
networks  are  entered  at  nodes  beginning  with  the  Letter  B.  The  unscheduled  maintenance  network  is 
entered  at  Node  G.  An  activity  network  is  entered  at  Node  A.  External  reconfigiration  networks 
are  entered  at  Nodes  beginning  with  the  Letter  Q.  The  internal  reconfiguration  network  is  entered 
at  Node  Rl.  Ordnance  down  loading  networks  are  entered  at  nodes  beginning  with  the  characters 
RS.,  and  ordnance  resupply  networks  begin  with  the  characters  ORD.  Finally  the  three  primary  call 
sections  are  entered  at  Nodes  D,  E,  and  F. 

4.  Form  12  -  Task  Definition.  Reference  Figure  9-4.  The  tasks  to  be  defined  on  the  Form  12s 
are  specified  in  the  Form  11  networks.  Note  the  pump  consumption  on  the  REPLH1  task.  In  order 
to  begin  processing  on  the  pump  itself  (next  indenture)  and  ensure  that  the  pump  repair  time  had  no 
effect  on  the  aircraft,  we  generated  a  PUMPH1  on  the  INSPH1  task.  Had  we  desired  to  have  the 
pump  repair  process  completed  but  not  specifically  follow  the  pump  itself,  we  would  still  have  an 
asterisk  in  Column  29  (generate)  but  no  associated  resource  described.  This  precludes  any  effect 
between  indenture  activity.  This  generate  action  has  the  effect  of  separating  the  repair  network 
(off  equipment)  from  the  aircraft  network  (on  equipment),  thereby,  not  impairing  the  aircraft 
availability.  A  similar  effect  between  each  indenture  is  also  accomplished  by  a  generate  action. 
The  resupply  and  other  off  equipment  ordnance  actions  are  also  triggered  through  a  generate  task. 

Both  general  and  task  specific  resoirce  substitution  was  activated  through  the  use  of  Form  12A 
records  and  their  companion  Form  13  defined  substitutions.  Post-flight  task  POSFLT  has  two  task 
specific  alternate  crews  specified  with  general  substitution  permitted  on  the  last  POSFLT's  12A 
record. 

Note  that  a  man  resource  GENTEC,  general  technician,  was  defined  on  Form  13  and  had  most  other 
defined  men  resources  defined  as  general  substitutes  for  it.  On  the  Form  16s  a  shift  authorization  of 
zero  was  specified  for  these  GENTECs  on  all  shifts.  The  net  effect  of  this  action  was  to  force  "task 
assist"  resource  substitution  any  time  a  requirement  for  a  GENTEC  was  requested.  When  using  this 
technique,  the  general  substitution  flagon  Form  12/1 2A  (Column  43,  52,  or  61)  must  be  used.  If  not, 
and  there  is  no  authorized  quantity  of  the  resource  (GENTEC  in  this  example),  that  set  of  resource 
requirements  can  never  be  satisfied.  The  associated  task  would  never  start  unless  other  alternate 
crews  are  specified. 

5.  Form  13  -  Resource  Definitions.  Figure  9-3.  For  each  resource  identified  as  a  task 
requirement  on  Form  12,  additional  information  was  developed.  The  "report  column"  specified 
correlates  to  the  information  on  Form  10,  Figure  9-2.  An  "authorized  quantity"  was  assigned  to  only 
those  resources  not  described  on  Form  16,  Figire  9-8.  These  were  assigned  shift  quantities  on  that 
form.  Note  that  on  Form  13,  separate  docks  were  identified  for  each  of  tne  four  major  parts  HI, 
H2,  Cl  1,  and  Cl 2.  The  hycfraulic  systems  failure  processing  was  controlled  at  subsystem  level  by 
failvre  dock  HI  and  H2.  The  communication  systems  failure  processing  was  controlled  by  the 
assemblies  Cll  and  Cl 2,  not  by  subsystem  Cl.  Clocks  CLKBMS,  CLKSMT,  and  CLKMIS  are 
ordnance  halt  docks  used  to  control  the  resupplying  of  ordnance  within  the  sample  problem.  Clocks 
CK2BM5,  CK2SMT,  and  CK2MIS  are  ordnance  halt  docks  used  to  control  ordnance  handling  during 
reconfiguration  down  loading.  Camera  Clock  CLKCAM  will  be  used  in  the  processing  of  the  internal 
equipment  camera. 

6.  Form  14  -  Clock  Decrements.  Figure  9-6.  Here  we  defined  that  the  SORTIE  task  when 
accomplished  was  to  decrement  the  Hycfraulic  System  docks  HI  and  H2  by  the  sortie  length.  Since  a 
particular  task  can  decrement  docks  only  one  way,  we  defined  an  additional  task  of  no  time  duration 


(DCRMT)  in  the  pre-sortie  networks  for  the  express  purpose  of  decrementing  the  communications 
subsystem  docks  by  a  constant  of  one  for  each  sortie  completed.  The  camera  dock  decrement  task, 
DFCAM,  is  processed  post-sortie  on  certain  missions.  Tasks  DECBMS,  DECSMT,  DECMIS,  DCBM52, 
DCSMT2,  and  DCM152  decrement  their  appropriate  halt  docks  for  proper  ordnance  control. 

7.  Form  15  -  Distributions.  Figure  9-7.  Two  empirical  distributions  were  defined,  one  interpolate, 
I  and  one  step  function.  One  is  used  in  defining  a  dock  failure  parameter  distribution  and  the  other 
I  defines  a  task  time  distribution. 

Form  16  -  Shift  Change  Polides.  Figure  9-8.  Two  shift  patterns  were  defined;  the  first 
represents  a  seven-day  week  with  standard  8-hour  shifts,  the  second  represents  a  continuous  daily 
cyde  with  9,  8  and  7-hour  shifts  used  for  munitions  spedalists  and  camera  technidans.  The 
assodated  resource  authorization  quantities  on  each  shift  are  given  for  each  resource. 

9.  Forms  17,  21,  22,  and  23.  Figures  9-9,  9-10,  9-11  and  9-12 

a.  Configuration  Management 

To  the  degree  possible,  a  narrative  description  of  the  data  development  and  analysis  process  will  be 
given  foiiowed  by  an  explanation  of  the  forms  required  to  implement  Configuration  Management. 
The  first  step  is  an  in-depth  analysis  of  all  possible  external  and  internal  configurations.  Once 
defined,  an  attempt  to  consolidate  them  into  as  few  different  configurations  as  possible  was  made. 
The  ground  rules  for  the  consolidation  process  should  indude,  but  not  be  limited  to,  consideration  of 
the  following  five  questions. 

(1)  What  types  of  answers  or  results  am  I  looking  for  and  what  impact  will  the 
different  configurations  have  on  these  results?  Areas  of  prime  consideration  indude  tasks  with 
significantly  different  times  or  crew  sizes,  operational  substitutability,  etc. 

(2)  How  many  of  the  possible  configurations  are  actually  used  and  to  what  extent?  It 
may  be  that  25  different  configurations  are  possible  but  only  6  or  7  constitute  95%  of  all  the 
missions  flown. 

(3)  During  the  process  of  configuration  changes  (reconfigurations),  are  there  spedal 
requirements  for  checkout  of  the  configurations,  i.e.,  spedal  tasks  or  resources  required? 

(4)  In  terms  of  internal  configurations,  are  there  any  spedal  networks  to  be  developed 
and  what  impact  might  they  have  on  aircraft  availability? 

(5)  What  impact  wili  reconfigurations  have  on  aircraft  pre-sortie  time? 

b.  External  Configurations 

For  the  purpose  of  describing  the  primary  aircraft,  let's  first  consider  only  the  external 
configurations.  Analysis  has  allowed  us  to  consolidate  the  number  of  external  configurations  down 
to  6:  (a)  CLEAN  (no  ordnance  or  weapon  rack(s).  (b)  BMS500  (conventional  500  lb  bombs  with  racks), 
(c)  MISSLS  (missiles  with  racks),  (d)  SMTBMS  (smart  bombs  with  racks),  (e)  RACKS  only  and  (f) 
RECPOD  (reconnaissance  pods  with  racks).  Table  9-1  is  the  Aircraft  External  Reconfiguration 
Matrix  which  depicts  the  time  and  munitions  load  crew  requirements,  plus  the  time  and  crew  chief 
requirements,  necessary  to  transform  an  aircraft  from  one  external  configuration  to  another.  This 
matrix  can  be  used,  along  with  advice  from  experienced  maintenance  personnel,  to  then  develop  the 
next  data  requirements  -  the  entry  points,  search  patterns,  and  reconfiguration  networks. 
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Notes: 

a.  Values  in  table  are:  task  time  in  hour  s/crew  sizes 

b.  All  crew  size  of  4  require  munitions  load  crews  and  crew  size  of  two  require  crew 

chiefs. 

c.  Reconfiguration  networks  specifier,  for  this  search  pattern  will,  when  processed,  result 
in  the  configuration  noted  in  col  1. 

d.  This  search  pattern  was  redefined  and  modified  as  RECON2  for  internal  Configuration 
Management. 

e.  This  search  pattern  was  redefined  and  modified  as  RLCON7  for  internal  Configuration 
Management. 

_ f,.  This  search  pattern  was  modified  for  internal  Configuration. 

The  action  necessary  to  utilize  the  data  in  Table  9-1  were  as  follows: 

(1)  During  Form  17  preparation,  the  proper  search  pattern  was  selected  based  upon 
both  mission  need  and  reconfiguration  timing.  Proper  entries  into  the  network  based  upon  pre-sortie 
processing  requirements  are  reflected  in  Figure  9-1,  Part  1.  The  PREFLT  activity  uses  the  default 
search  pattern  (name  the  same  as  the  aircraft)  because  this  se.vch  pattern  must,  by  definition, 
search  all  external  configurations.  Internal  configuration  should  not  be  considered  in  this  search 
pattern.  Note  that  since  PREFLTs  are  activities,  we  are  not  collecting  statistics  on  them  in  the 
PSR  (no  column  assignment). 

(2)  Pseudo-preparation  of  the  Search  Patten  definitions,  Form  21,  was  then 
accomplished  considering  only  the  external  con  :igtration.  Addition  of  internal  configuration  data 
retirements  followed  prior  to  actually  filling  out  Form  21.  Section  D9c  discusses  the  Internal 
Configuration  data  development. 

(3)  Within  the  Form  11s  there  should  be  def.ned  new  or  modified  network  sections 
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describing  the  externa!  reconfigurations  for  the  seven  search  patterns,  RECON  1  through  RECON7. 
These  reconfiguration  networks  are  found  in  Figire  9-1,  Part  5.  The  associated  Form  1  Is  are  shown 
in  Figure  9-5. 


(4)  New  tasks  must  also  be  defined  on  the  Form  12  (see  Figure  9-4).  These  tasks  are 
those  used  in  the  above  networks. 

(5)  In  the  sample  problem  each  mission  was  given  its  own  entry  point  (See  figure  9-1, 
Part  1).  This  was  done  in  order  to  simplify  the  example  and  to  show  the  consumption  and  generation 
of  the  appropriate  ordnance.  This  need  not  always  be  the  case,  however.  If  the  missions  are  of  a 
similar  nature,  they  can  both  utilize  the  same  entry  point.  In  cases  involving  different  mission 
types,  the  networks  can  be  drawn  as  in  the  sample  pi  oblem  with  each  mission  having  its  own  entry 
point,  or  if  desired,  one  basic  t  ight  line/mission  processing  network  leading  to  a  sortie  with  separate 
networks  following  the  sortie  showing  consumption  and  generation  of  the  appropriate  ordnance.  This 
procedure  will,  of  course,  require  clocks  and  var  ous  combinations  of  the  H,  J  and  possibly  K 
selection  modes  to  control  the  entry  into  the  proper  post  sortie  network  section  at  the  proper  time. 
However,  the  addition  of  internal  configurations  also  is  made  less  complicated  when  separate 
Mission  entry  points  and  pre-sortie  ne  works  are  used. 

(6)  The  second  aircraft  was  defined  as  having  only  one  configuration,  CLEAN. 

c.  Internal  Configuration  (applies  only  to  the  original  aircraft) 

Given  the  above  resolution  of  external  configuration,  an  analysis  was  made  of  the  internal 
configuration  usage.  On  Forms  21  and  23,  a  camera  was  defined  .is  the  internal  equipment  on  the 
F4D  aircraft  for  three  missions:  INTFcDl,  RECON,  and  INTRD3.  At  the  start  of  simulation,  one 
camera  as  authorized  on  Form  !’2  is  placed  on  tie  aircraft.  Within  each  search  pattern  that 
considers  internal  configuration,  a  check  is  made  first  to  locate  aircraft  configured  with  one  camera 
(see  Table  9-1  and  Forms  21  and  23).  If  enough  aircraft  are  located,  then  a  check  is  made  for 
aircraft  configured  with  t  camerau.  When  these  aircraft  are  located,  they  must  be  internally 
reconfigured  to  contain  one  camera  by  processing  the  internal  reconfiguration  network  defined  on 
Form  11  with  the  Reconfiguration  Entry  Node  specified  on  Form  21.  The  internal  reconfiguration 
network  is  shown  in  Figure  9-1,  Part  4  with  entry  node  Rl. 

The  use  of  trigger  node  ADDCAM  is  specified  ir  the  internal  reconfiguration  network  and  is 
implemented  to  add  one  camera  to  the  internal  equipment  on  those  aircraft  which  contain  0 
cameras.  The  "add"  action  of  ADDCAM  trigger  node  is  defined  on  Form  22.  The  trigger  node 
SUBCAM  causes  the  opposite  action  to  take  place,  hat  of  subtracting  one  camera  from  the  internal 
equipment  on  an  aircraft  and  is  also  shown  in  the  network  in  Figure  9-1,  Part  3  beginning  with  entry 
node  G.  This  maintenance  network  will  be  processed  when  the  camera  clock  CLKCAM  breaches 
zero. 

In  the  vxischeduled  maintenance  network  the  task  used  at  node  SUBCAM  "generates"  a  camera  "part" 
for  shop  repair,  thus  making  the  camera  a  supply  item,  as  well  as  internal  equipment.  The  camera  is 
not  replaced  on  the  aircraft  during  unsdteduled  maintenance,  i.e.,  no  consume  demand  is  made  for 
the  camera.  However,  in  the  reconfiguration  network,  the  task  use  J  at  node  ADDCAM  does  consume 
the  camera.  When  using  Internal  Configuration  equipment,  consume  and  generate  actions  are  not 
required,  but  if  used,  permit  the  internal  equipment  items  to  be  reported  in  several  of  the  Main 
Module  reports  including  the  PSR,  This  provides  for  easier  checkout  of  Internal  equipment  trigger 
node  visage. 

Caution:  Care  should  be  taken  to  not  process  either  the  plus  or  minus  trigger  nodes  in  a  manner 
where  the  maximum  authorized  is  exceeded,  or  the  internal  ecfiipment  quantity  becomes  negative. 


10.  Form  20.  Figure  9-13.  Tt>;  primary  record  of  importance  Sire  is  the  second  card  on  which 
we  have  asked  for  a  mission  and  sortie  listing  (LIST)  to  be  made  ,s  well  as  the  exogenous  tape 
normally  produced.  Also  we  established  that  only  a  60-day  flying  program  be  generated  and  gave  oir 
code  identifier  3.3  .BL  (sample  problem  #3.3,  baseline  exogenous  file)  to  the  ,nput  Module.  The 
remainder  of  the  data  records  are  used  to  generate  the  flying  program. 

One  option  not  mentioned  before  is  used  on  the  activity  f’REFLT  (pre- flight).  Here  we  wish  to  cause 
all  aircraft  not  cirrently  in  use  to  do  the  particular  pre-flight  inspection  task,  by  placing  a  "99"  in 
the  maximum  mission  size,  the  simulation  model  krows  that  only  those  aircraft  not  currently  in  use 
are  to  do  this  task.  All  other  numbers  placed  in  these  size  columns  are  demands  for  explicit 
quantities  of  aircraft.  A  cancel  time  of  3.5  hours  was  given  for  this  activity  which  was  to  begin  at 
0300,  therefore,  if  any  of  the  aircraft  required  to  do  this  PREFI T  task  have  not  started  by  0630,  the 
activity  for  that  aircraft  will  be  cancelled 

E.  Input  Module  Processing. 

See  Chapter  III  for  a  description  of  each  report.  Figures  9-14  to  9-39  represent  the  Input  Module 
printout  for  the  sample  problem  as  submitted.  Additional  pages  of  particularly  long  reports  have 
been  omitted.  Each  report  is  primarily  a  listing  o'  the  data  records  with  expanded  spacing  between 
the  entries.  Sequence  number  would  have  been  printed  at  thn  right  of  each,  report  if  the  sample 
problem  records  had  been  sequence  numbered.  Sequence  numbers,  however,  are  a  significant  aid  in 
data  base  changes  especially  when  ihe  data  package  is  large.  See  Chapter  III,  Section  G,  for  report 
description. 

Normally  while  developing  a  package,  embedded  diagnostics  .ire  prevalent,  but  on  a  completely  clean 
package  such  as  this,  only  warning  and  informational  messages  are  embedded.  However,  summary 
diagnostics  and  messages  are  always  given  as  in  Figure  9-28  and  9-29. 

Figures  9-30  through  9-38  are  the  dictionaries  containing  the  numbers  assigned  to  the  particular 
resource,  clock  or  task,  etc.  Figire  9-39  is  only  a  partial  of  the  Initialization  data  report  since  this 
report  is  voluminous.  Programming  knowledge  is  >  equired  for  its  interpretation.  The  first  part  of  it 
shows  the  transfer  of  the  necessary  dictionaries  to  the  Main  Module  and  Post  Processor  Module. 

F.  Main  Module  Processing 

The  problem  was  simulated  for  60  days  with  a  10  day  warmup.  Within  this  run,  a  sample  of  all 
normal  and  optional  reports  was  requested.  These  reports  were  scattered  throughout  the  chapter 
only  for  the  intended  purpose  of  proper  spacing  to  allow  two  page  report*  to  be  properly  displayed, 
therefore  they  may  seem  out  of  sequence. 

General  discussion  on  some  of  the  reports  iri  Figures  9-40  through  9-54  follows. 

Initialization  -  Figure  9-41.  This  is  the  Main  Module  printou  of  the  initialization  produced  by  the 
Input  Module  and  is  provided  only  to  show  its  existence.  Programming  knowledge  is  necessary  to 
completely  understand  this  report.  The  report  itself  is  voluminous  and  only  partially  displayed. 

Change  Cards  -  Figure  9-42.  This  report  reflects  all  the  changes  we  requested  during  this  run.  See 
Chapter  VII  for  CHANGE  card  descriptions. 


Figures  9-43  through  9-54  are  specific  Main  Module  reports  either  requested  in  the  change  card  file 
or  provided  automatically  at  specified  frequencies  and  as  such  should  be  self-explanatory. 
Reference  Chapter  IV,  Section  D,  for  report  descriptions. 

f 

Figure  9-55  is  an  example  of  a  main  module  run  abort  and  has  no  relationship  to  the  remaining 
figures.  It  was  a  forced  abort  included  only  to  uhow  a  sample  if  the  abort  traceback  reports  for 
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identification  purposes. 


G.  Summary 

This  sample  problem  has  a  complete  set  of  output  reports  shown  here.  The  Main  Module  results 
obtained  during  implementation  on  another  computer  will  only  be  similar  to  but  not  duplicated  in 
content,  since  the  simulation  is  based  upon  randcm  draws.  However,  all  Input  Module  processing, 
Figires  9-14  though  9-39,  and  Figures  9-40  through  9-42  of  the  Main  Module  processing  should  be 
duplicated. 

The  sample  itself  must  not  be  considered  a  good  representation  of  some  base  activity  or 
maintenance  but  serves  as  an  excel  ent  example  data  package.  The  Main  Module  run  processed  is  a 
constrained  case.  This  was  done  to  force  certain  reports,  such  as  the  backorder  status  (BOSTAT) 
report  to  contain  information  for  illustrative  purposes. 

All  transaction  data  has  been  tapped  out  for  use  by  the  Post  Processor  Module.  However,  the 
reports  from  the  various  post  processors  are  not  included  in  this  cliapter,  but  samples  of  them  are 
included  in  Chapter  V  along  with  a  description  of  the  specific  post  processor. 
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FIGURE  9-1.  PART  4.  SAMPLE  PROBLEM  3.5'S  NETWORKS  -  INTERNAL  CONFIGURATION 
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FIGURE  9-3.  SAMPLE  PROBLEM  3.5’s  FORM  13 
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FORM  17  •  TASK  DEFINITIONS 
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FIGURE  9-5.  SAMPLE  PROBLEM  3.5s  FORM  11 
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FORM  11  -  TASK  NETWORK 
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LOGISTICS  COMPOSITE  MODEL  loom  n  -simulation  model  inputs 

FORM  14  -  FAILURE  CLOCK  DECREMENTS 
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FIGURE  SI-9.  SAMPLE  PROBLEM  3.5's  FORM  17 
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FIGURE  9-18.  TASK  NETWORK  INPUT  DATA  -  SP3.S’S  FORM  11  PROCESSING  (CCWT'D) 
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FIGURE  9-27.  SUMMARY  DIAGNOSTICS  -  SP3 
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X.  DATA  DEVELOPMENT  METHODOLOGY 


A.  Introduction 

An  LCOM  data  base  can  be  structured  in  varied  detail  depending  on  the  level  of  abstraction  of  the 
aircraft  maintenance  environment  being  simulate j.  The  environment  can  oe  described  in  extreme 
detail  or  simplified  to  the  extent  of  representing  maintenance  time  on  the  aircraft  as  a  single  task. 
The  manner  of  representing  the  maintenance  activity  depends  on  the  problem,  the  data  availability, 
and  the  user's  preference.  The  network  completely  depends  on  the  problem. 

This  chapter  is  primarily  included  as  an  aid  to  new  users  who  may  he  defining  a  sizeable  data  base. 
Data  collection  and  development  problems  are  emphasized  to  provide  insights  to  any  future  large  or 
medium  sizes  applications.  Only  the  unscheduled  maintenance  networks  are  discussed  but  similar 
problems  and  techniques  would  appl)  to  most  networks,  e.g.,  scheduled  maintenance. 

Basically,  tasks  described  in  an  unscheduled  maintenance  networc  represent  a  complete  set  of 
maintenance  actions,  i.e.,  the  sequence  of  events  leading  to  an  operationally  ready  aircraft  and  to  the 
repair  of  a  removed  part.  In  order  to  describe  these  steps,  it  is  necessary  to  describe  who  takes  the 
maintenance  action,  what  equipment  is  needed  to  perform  the  action,  and  how  long  the  action  takes. 
Also,  required  parts, equipment,  manpower,  and  skills  must  be  specified  in  order  that  a  maintenance 
action  may  draw  the  appropriate  resources  for  use  in  [>erforming  the  task.  Broadly  speaking,  one 
identifies  the  subsystem  (or  Line  Replaceable  Unit  (LRU)),  delines  t'ne  sequence  of  maintenance 
actions  leading  to  conditioning  of  the  aircraft  (and 'or  the  rep>air  of  removed  parts),  and  defines  each 
repair  step  or  task  in  terms  of  the  resoirces  and  the  time  needed  to  perform  the  repair  task. 

B.  Definition  and  Description  of  Data  Elements 

Three  data  elements  will  be  discussed:  the  network,  the  task,  and  the  resource.  Actually,  the  three 
elements  form  a  hierarchy.  A  network  is  made  up  of  tasks  and  a  task  is  described  by  the  resources  and 
time  required  to  accomplish  it. 


1.  Network 

One  can  think  of  a  maintenance  netwotk  as  an  ordering  of  tasks  which  occir  from  the  time  an  aircraft 
requires  maintenance  until  the  aircraft  has  become  operationa’ly  ready  again  arid  any  failed  parts  are 
either  repaired  or  have  been  replaced  in  inventory  by  a  new  one.  The  term  network  simply  describes  a 
convenient  drawing  process  which  allows  us  to  represent  on  paper  th;  sequence  of  repair  tasks  we  wish 
to  describe. 

Figure  10- 1  is  a  very  simple  network  which  illustrates  most  of  the  oasic  features  to  be  incorporated. 
The  circles,  or  nodes,  can  be  thought  of  as  points  in  time.  For  instance,  node  B  is  the  point  in  time 
which  follows  task  100  and  precedes  task  101..  The  lines  between  nodes  can  be  thought  of  as  tasks 
which  occir  diring  an  interval  of  time.  Thus,  task  101  begins  at  time  B  and  ends  at  time  C. 


100 


10M 


Figure  10-1.  EXAMFLE  OF  A  SIMPLE  TASK  NETWORK 
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Alternatively,  we  can  say  that  tasl;  101  directly  follows  task  100  and  precedes  102  and  103,  and  that  it 
takes  15  minutes.  Uaing  the  convention  of  nodes  and  lines  we  can  also  show  tasks  which  proceed 
independently  of  each  other  such  ar  102  and  103. 

In  the  development  of  a  network,  the  crucial  thing  is  to  Identify  all  the  possible  ways  in  which  the 
repair  of  an  aircraft  and/or  parts  might  occur,  and  the  order  in  which  they  should  occur.  If  the 
network  shows  a  part  being  removed,  then  a  replacement  logically  must  occur  sometime  subsequent  to 
the  removal.  Oust  when  it  occurs  may  well  depend  uoon  ths  part  and  its  repair  policy  which  must  be 
researched  in  order  to  properly  draw  the  network.  Also,  one  must  show  the  disposition  of  the  removed 
part.  Is  it  repaired  in  the  shop,  at  the  depot,  or  is  it  discarded  and  a  new  one  ordered? 

2.  Tasks 

The  second  data  element,  tasks,  are  the  elements  fron  which  a  network  is  built.  Obviously,  the  same 
network  can  be  described  in  terms  of  a  few  very  general  tasks,  or  many  very  specific  tasks.  For 
example,  one  might  simply  have  a  ask  called  "repair"  to  describe  all  actions  performed  during  the 
repair  of  a  failed  item  or  one  might  identify  very  s  >ecific  repair  steps,  such  as  "loosen  six  bolts,"  as 
separate  tasks.  In  part,  the  question  of  how  much  detail  should  be  represented  in  defining  separate 
tasks  will  be  answered  by  either  the  purpose  of  the  study,  the  data  sources  used,  or  both.  However, 
one  should  avoid  the  tendancy  to  be  too  detailed  in  task  descriptions.  Two  to  five  tasks  should  be 
adequate  for  the  usual  Dart  repair  network;  however,  complex  parts  may  require  more  tasks. 

During  the  task  network  development,  a  modified  version  of  the  Air  Force  Maintenance  Data 
Collection  (MDC)  System  Action  Taken  Codes  furnishes  ar  adequate  list  of  task  descriptions.  This  list 
has  the  virtue  of  being  short  and  is  capable  of  describing  tasks  at  the  level  of  aggregation  which  is 
desired.  'See  Table  10-1.  The  data  comes  from  the  Common  Data  Extraction  Program,  one  of  the 
LCOM  Iljsupport  programs  that  analyzes  the  MDC  System  tapes. 

3.  [  Resources 

In  order  to  describe  a  given  task,  one  needs  more  than  a  simple  action  description.  One  must  also 
include  the  resources  and  expected  lime  required  to  accomplish  the  action.  The  types  of  resources 
which  ate  to  be  specified  are  man,  AGE  (Aerospace  Ground  Equipment),  parts  and  facilities.  Each  task 
must  be  defined  in  terms  of  what  resources  will  be  used  during  the  performance  of  that  task.  For 
example,  a  normal  task  requires  manpower  of  one  or  more  skill  classes  and  grades,  perhaps  some  AGE, 
and  if  it  is  a  replacement  task,  a  serviceable  patt  must  be  available  with  which  to  make  the 
replacement.  However,  some  tasks  may  take  no  significant  resources.  For  example,  an  item  sent  to  a 
depot  for  repair  and  returned  ten  days  later  takes  no  significant  base  manpower  or  AGE  during  the  ten 
days  but  does  represent  an  unavailable  part  for  the  ten  days.  Hence,  it  is  a  task  resulting  from  a 
failure  which  affects  the  base  inventory  of  parts  lor  ten  days.  In  general,  what  resources  will  be 
needed  to  accomplish  a  task  depends  entirely  upon  the  action  defined  and  the  part  under  consideration. 

The  resoirees  associated  with  the  wrious  tasks  must  be  defined  according  to  their  type,  their  cost, 
their  failure  rate  if  any,  and  resource  substitutions  which  can  be  made  in  case  the  specified  resource 
should  not  be  available. 

C.  Labels  -  Rules  and  Suggestion;  for  Labeling 

We  have  said  that  the  task  network  is  composed  of  nodes,  tasks,  and  resources.  Each  of  these  elements 
needs  a  numbering  or  labeling  scheme.  The  labeling  scheme  should  be  such  that  one  can  readily 
differentiate  between  the  differert  elenents,  should  be  flexible  enough  to  identify  subclasses  such  as 
skill  levels,  and  finally  must  be  no  'ongei  than  six  characters  in  length. 

Fortunately,  standard  Air  Force  coding  systems  for  the  elements  of  interest  usually  meet  these 
conations.  Currently,  Work  Unit  Codes  are  five  digits  in  length  and  identify  adequately  the  major 
parts  on  an  aircraft.  Air  Force  Specially  Codes  (AFSC)  do  not  normally  exceed  six  digits  and  identify 
the  skill  qualifications  and  levels  of  maintenance  personnel.  Since  AGE  has  no  convenient  six  digit 


TABLE  10-1 


LOOM  ACTION  CODE  DEFINITIONS 


LCOM 

Action 

Code 

Description 

Includes  MDC 

V 

Operational  Check 

X  Action  Taken  Codes 

T 

Troubleshoot 

Y  Action  Taken  Codes  excluding  812  How 
Mai  Code,  and  H  Action  Taken  Codes  when 
an  "R"  or  "M"  LCOM  Action  occurs  under 
same  JCN 

0 

N 

E 

Q 

R 

Unscheduled  re¬ 
move  &  Replace 

R,  ?,  and  Q  Action  Taken  Codes*  exclud¬ 
ing  those  with  How  Mai  Codes  799,  800, 
803,  804,  and  805  (includes  associated 
"M"  work) 

u 

I 

RT 

Scheduled  Re¬ 

R,  P,  and  Q  Action  Taken  Codes*  with  Hoi 

p 

move  &  Replace 

Mai  Code  803 

M 

E 

M 

Repair  in  place/ 

F,  G,  J,  K,  L.  V,  and  Z  Action  Taken 
Codes 

N 

minor  maintenance 

T 

H 

Cannot  duplicate 
malfunction 

All  H  Action  Taken  Codes,  and  Y  Action 
Codes  with  How  Mai  Code  812  (an  "R"  or 
"M"  Action  under  same  JCN  causes  "H" 
to  become  "T") 

X 

Remove  and  replace 
to  facilitate  other 
maintenance 

All  S  Action  Taken  Codes,  and  R,  P,  &  Q 
Action  Taken  Codes*  with  How  Mai  Codes 
' 99,  800,  804,  and  805 

N  Bench  checked 

not  reparable 

0  this  station  (NRTS) 

F 

F  K  Bench  checked  no 

repair  required 
E 

q  W  Bench  checked  and 

U  and  repaired 

I 
P 

M  C  Bench  checked  and 

E  repair  deferred 

N 
T 

D  Disassemble/re¬ 

assemble 


*  Formula  for  equating  P&Q  units 


D,  1,  2,  3,  4,  5,  6,  7,  8,  and  9  Action 
Taken  Codes  (includes  associated  “C"  & 
"D”  work) 

B  and  X  Action  Taken  Codes  (includes 
associated  ’C"  and  "D"  work) 

A,  F,  G,  J,  K,  L ,  V,  and  Z  Action  Taken 
Codes  (Includes  associated  "C"  and 
D"  work) 

C  Action  Taken  Codes  which  cannot  log¬ 
ically  be  combined  with  an  "N”,  "K", 
or  "W"  action 

M  and  N  Action  Taken  Codes**  which  can¬ 
not  logically  be  combined  with  an  "NM, 
"K",  or  "W"  action 


to  F  units 


-  —  (rounded  up) 


+ 


Q  units 
2 


(rounded  down) 


**M  and  N  units  counted  the  same  as  P  and  Q  units  respectively. 
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code  system  which  covers  all  major  equipment,  it  may  be  identified  by  its  five  digit  work  unit  code  or 
a  special  code  may  be  developed. 

To  distinguish  between  parts,  men  and  AGE,  a  special  character  can  be  placed  in  front  of  the  five  digit 
work  oode.  A  period  could  serve  to  distinguish  parts,  while  another  special  character,  the  dollar  sign, 
could  serve  to  identify  the  AGE.  Any  special  characters  available  on  a  computer  will  serve  the  same 
purpose.  One  must  remember,  however,  that  these  labels  can  have  no  more  than  six  characters 
including  special  characters  which  may  be  attached  for  differentiation  purposes. 

The  labeling  of  nodes  is  also  restrict**!  to  six  characters.  Each  two  digit  Work  Unit  Code  can  be 
associated  with  an  alphabetic  character  which  is  used  as  the  first  character  in  the  node  label  whenever 
a  network  is  being  drawn  for  a  part  belonging  to  that  two  digit  Work  Unit  Code  group.  The  remaining 
characters  are  labeled  numerically  and  consecutively.  This  approach  prevents  duplicate  labels  for 
different  nodes. 

Task  labels  or  identifications  can  have  up  to  six  characters.  If  one  combines  the  modified  Action 
Taken  Code  (Table  10-1)  with  the  Work  Unit  Code  of  the  par*  or  system  which  is  being  acted  upon,  the 
task  label  will  describe  what  is  being  done  to  what  part.  The  important  concept  to  remember  in 
developing  and  assigning  labels  is  that  a  label  must  be  unique  within  a  p-oup.  However,  a  task  could 
have  the  same  name  as  a  node  or  resource. 

D.  Selection  Procedire  for  Critical  Parts 

One  of  the  constraints  that  one  quickly  encounters  is  the  limited  number  of  parts  which  the  model  can 
represent  in  network  form.  This  limitation  occurs  because  an  average  of  eight  tasks  are  required  to 
describe  the  maintenance  actions  for  one  part.  Each  task  requires  an  average  of  four  computer  words 
of  storage.  Thus,  500  parts  need  approximately  4000  tasks  which  consume  approximately  16,000  words 
of  storage.  An  attempt  to  define  the  maintenance  network  for  all  parts  of  an  aircraft  could  easily 
exceed  the  core  capacity  of  a  lar  >e  computer.  As  a  result,  a  selec  tion  procedire  is  needed  to  identify 
the  limited  number  of  items  which  are  of  interest  to  the  user. 

The  user  will  be  interested  in  assessing  the  impact  of  operations  policies,  maintenance  policies,  supply 
policies,  manning  policies,  etc.,  upor  the  whole  support  system  and  its  capability  to  perform  its 
missions.  For  a  meaningful  simulation,  it  is  necessary  to  represent  all  critical  portions  of  the  support 
system,  but  not  every  piece  of  it.  The  question  is  then  to  determine  what  p>ortion  of  the  total  activity 
is  represented  by  tne  selected  parts.  If  these  ,arts  .are  the  items  which  generate  most  of  the 
maintenance  workload  and  the  demand  for  manpower  and  spares,  then  a  realistic  pictire  is  obtained 
from  the  simulation. 

In  order  to  identify  items  which  have  a  high  impact  up»n  the  support  system,  one  can  go  to  historical 
data,  if  available,  or  look  at  engineering  estimates.  These  sources  should  identify  which  items  have 
high  failure  rates  and  consume  large  quantities  of  man-hoirs.  These  same  items  are  normally 
reparable  and  tend  to  he  high  cost  items.  Fortunately,  then,  the  items  which  have  a  high  impact  upon 
maintenance  will  also  tend  to  have  a  high  impact  upon  supply.  Other  items  are  certainly  significant, 
but  their  analysis  is  not  best  accomplished  in  a  simulation  model. 

Another  element  in  the  selection  procedire  is  the  usage  of  AGE.  It  is  desirable  to  include  items  which 
require  high  cost  pieces  of  AGE.  ,'hese  parts  tend  to  be  the  same  as  the  high  cost,  high  man-hoir 
consuming  parts.  As  an  initial  selection  procedire,  one  can  select  historically  high  man-hoir 
consumption  items,  or  high  cost  reparable  items,  or  high  failure  rate  items  and  often  end  up  with 
similar  lists  of  parts.  Such  a  procedire  is  not  guaranteed  to  identify  the  best  list  of  parts  which  might 
be  selected,  however,  the  advantage  of  speed  and  ease  make  it  useful  as  an  initial  approach.  Later 
additions  or  deletions,  as  tlie  need  arises,  can  be  made. 

E.  Network  Development 

1.  Possible  Data  Soirees 

The  source  of  information  used  in  the  development  of  maintenance  task  networks  will  depend  to  a 
large  extent  upon  the  state  of  the  weapon's  deveiooment.  Foi  weapons  which  are  already  operational, 
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many  soirees  can  be  found.  For  weapons  still  in  the  conceptual  stage,  reliance  will  have  to  be  placed 
upon  design  data  and  information  from  similar  weapons.  Since  the  repair  stepr  tend  to  be  similar 
within  various  subsystems,  it  is  likely  that  network  development  wi'l  in  reality  become  a  process  of 
ref ining  past  developments  rather  than  starting  from  the  beginning. 

Several  soirees  are  useful  in  the  development  and  refinement  of  networks.  Contractor  firnished  data 
sets  forth  in  detail  the  tasks  necessary  to  repair  a  failed  item.  Most  of  the  data  needed  to  define 
networks  is  available  from  the  contractor  include  estimates  of  task  times  and  the  resources  necessary 
to  perform  the  tasks.  However,  a  good  deal  of  familiarity  with  thr  contractors  data  may  be  needed  to 
dig  out  the  necessary  information  since  this  data  is  rot  explicitly  developed  for  network  purposes. 

A  potential  problem  in  using  a  contractor  data  sou  ce  for  networks  is  that  it  often  tends  to  make  the. 
assumption  that  the  failed  item  is  clearly  identifiable.  Thus,  the  ;equence  of  tasks  which  are  needed 
to  locate  the  failed  part  is  often  left  out.  Another  problem  with  contractor  data  is  that  its  task  time 
and  failire  rate  estimates  are  often  not  based  upon  actual  field  experience.  It  is  advisable  to  augment 
contractor  data  with  information  from  soirees  which  have  direC:  field  experience  with  the  part  and  its 
maintenance  tasks.  Field  data  may  provide  improvements  upon  failure  rate  estimates,  while 
maintenance  personnel  who  have  had  experience  with  actual  repair  of  the  same  or  similar  items  can 
provide  improved  task  time  estimates.  With  this  type  of  augmentation,  contractor  data  should  prove 
adequate. 


2.  Data  Generation  Procedure  -  An  Example 


The  following  example  was  developed  in  order  to  illustrate  seme  of  what  has  been  presented.  See 
Figure  10-2. 

The  network  is  relatively  simple.  The  part  selected  is  a  pump  in  the  PC  11  hydraulic  system.  The 
Work  Unit  Code  (WUC)  of  the  pump  is  45123.  Tne  system  to  which  the  pump  belongs  is  the  PC  11 
hydraulic  system— WUC  45120.  According  to  contractor  data,  if  a  pu.np  failure  occurs,  the  first  action 
which  must  be  performed  is  a  troubleshoot  action  upon  the  hydraulic  system.  This  is  done  by  the  crew 
chief  (43171C)  and  it  takes  him  8  minutes.  We  call  the  task  T45120  since  T  is  the  troubleshoot  action 
code  (Table  10- 1)  and  45120  is  the  system  upon  which  troubleshooting  is  performed.  The  report  of  the 
failire  contained  sufficient  information  ior  the  c^ew  chief  to  know  which  system  was  causing  the 
problem. 


Following  the  troubleshooting  task,  the  pump  is  removed  and  replaced  by  a  new  pump  from  supply. 
This  task  (R4512B)  requires  a  pump  for  replacement  purposes,  a  specialist  (42152)  and  takes  45  minutes 
to  perform.  Following  the  pump  exchange,  the  filters  are  removed  and  replaced  by  the  same  person, 
requiring  a  new  set  of  filters  and  199  minutes.  The  filters  are  assumed  to  be  available.  This  is  task 
R4512K  performed  on  the  filters  -  WUC  451 2K. 

The  last  task  done  on  the  aircraft  is  a  functional  test  of  the  hydraulic  system,  45120.  This  task  is 
labeled  V45120  since  V  is  the  Action  Code  for  functional  testing.  This  task  requires  a  43171C,  a 
431 51C,  and  42152;  i.e.,  the  crew  chief,  his  helper,  and  a  hydraulic  specialist.  It  takes  317  minutes.  In 
reality,  this  task  is  a  combination  of  several  tasks  such  as  turning  on  the  aircraft,  checking  the  system, 
and  servicing  the  aircraft  following  maintenance.  However,  it  aopeared  that  all  actions  could  be 
combined  into  one  task  without  unduly  altering  the  actual  events.  Oeneiaily,  this  combination  can  be 
done  whenever  the  same  reso trees  are  used  to  perform  sequential  tasks.  In  this  case,  the  times  can 
simply  be  added  together. 

Backing  up  in  the  network,  the  task  N4512B  is  that  which  represents  sending  the  failed  pump  to  the 
depot  and  receiving  a  new  one  from  the  depot  twelve  days  later.  The  twelve  day  time  interval  in  an 
estimate  of  the  total  pipeline  time  between  base  and  depot.  Other  improved  estimates  can  be  used.  It 
should  be  noted  that  no  base  resources  are  assigned  to  the  task.  This  is  because  the  part  is  in  transit  or 
at  the  depot  for  almost  all  of  the  time;  hence,  no  base  resources  re  required. 


The  final  task  shown  In  Figure  10-2,  Z*5I2\  Is  a  special  purpose  task  which  has  been  devised  to 
Improve  upon  the  ability  of  this  network  to  completely  represent  all  base  maintenance.  In  general,  the 
Z  task  attempts  to  represent  an  average  amount  ot  maintenance  which  would  be  performed  on  several 
parts  In  the  system  not  Including  the  jpecitlc  part  'ttder  coivsideratlon.  This  Is  done  for  two  reasons. 
First,  It  hol«t»  a  place  In  the  network  for  later  additions  to  the  network.  Second,  In  a  gross  sense  It 
represents  the  maintenance  activity  on  the  aircraft  (not  shop)  which  has  not  been  accounted  for 
specifically  In  the  network.  The  time  used  for  this  task  Is  an  estimate  of  the  average  time  for  the 
average  parts  represented  !n  the  system.  The  resources  needed  for  this  average  task  are  a  composite 
of  what  might  be  required  for  repen  t  on  the  o'.lter  parts,  but  normally  does  not  Include  lower  Indenture 
parts  consumptions. 

As  the  network  becomes  more  complete,  the  need  and  effect  of  the  Z  task  Is  reduced.  It  Is  really  an 
interim  step  which  may  be  surpiante  I  at  a  later  time  by  the  actual  tasks  which  the  tingle  average  task 
is  intended  to  represent. 

Once  the  network  is  established,  selection  modes  may  be  assigned  to  the  respective  tasks.  For  the 
example  network,  the  tasks  art  given  either  an  F,  D.  or  E  selection  mode.  The  tasks  which  are 
performed  only  if  they  lead  to  a  failure  are  given  an  F  selection  mode.  The  R*3|2B  is  mode  F  since  it 
is  controlled  by  a  resource  clock  with  a  mean  value  of  200  flying  hours.  Also,  the  preceding  task 
T* 3120  following  the  G2  node  (the  sode  following  the  post  flight  Inspection  where  (allures  are 
discovered)  must  be  given  mode  F.  It  the  example  net  wot  k,  all  tasks  following  R*312B  receive  a  D 
mode  since  these  :asks  are  to  be  done  If  the  task  I?  accomplished.  For  example,  following  the  removal 
and  replacement  of  the  pump,  the  filters  are  removed  ana  replaced  (Re  31 2K)  and  the  pump  Is  sent  to 
the  depot  for  repairs.  These  tasks  follow  Re  3|  2B  and  are  all  tliree  done. 


Note  that  the  pump  (4512B)  is  consumed  by  task  R4512B  and  replaced  in  stock  by  task  N4512B.  The 
other  components  of  the  system  (45120)  are  not  •  xplicitly  simulated  and  the  workload  they  generate 
for  personnel  is  included  in  task  Z4  51 2*.  The  failure  rates  for  these  other  components  are  too  low  to 
include  them  individually.  Finally,  this  entire  branch  of  the  network  is  assigned  mode  F  since  it  is 
controlled  by  the  "dock"  value  which  has  a  mean  value  of  373  flying  hoirs.  This  373  hoirs  does 
represent  an  average  of  the  failure  rates  of  the  "other  components." 

After  the  network  is  developed,  the  associated  data  is  transcribed  onto  the  appropriate  input  forms. 

3.  Some  Problems  In  Network  Development 

One  of  the  more  vexing  problems  identified  during  initial  network  development  may  be  the 
incompleteness  of  the  data.  As  pieviously  stated,  some  data  sources  assume  the  failire  has  been 
identified.  Thus  a  substantial  number  of  tasks  may  be  omitted  from  the  description.  You  can  correct 
this  problem  by  having  people  who  are  familiar  with  tl*  aircraft  develop  the  network.  They  could  then 
apply  their  knowledge  and  add  troubleshooting  and  other  tasks  where  they  felt  there  was  a  requirement 
which  was  not  induded.  Most  systems  need  this  type  of  augmentation. 

A  final  problem  is  relating  parts  to  the  proper  systems.  Given  c  part  failure,  one  usually  checks  the 
system,  subsystem,  or  set  to  which  it  belongs  in  order  to  identify  the  failed  item.  In  some  cases, 
however,  the  work  unit  code  manual  did  not  pla».e  the  part  in  its  prope'  functional  category.  For 
example,  a  part  might  belong  to  a  grouping  of  parts  which  would  be  functionally  related  but  spread  all 
over  the  aircraft.  However,  the  Work  Unit  Code  system  should  be  used  since  the  maintenance  data  is 
readily  available  in  this  form. 

4.  Follow-on  Network  Development  Efforts 

The  network  shown  in  Figure  10-3  is  typical  of  networks  developef  for  a  Fire  Control  System.  An 
explanation  follows. 

The  W  task  shown  between  nodes  1  and  2  designates  all  unscheduled  orv-equipment  maintenance 
actions.  The  F  indicates  that  this  section  of  the  n»twork  will  not  be  entered  unless  there  is  a  failure  or 
a  requirement  for  on-equipment  maintenance.  The  mean  time  between  maintenance  actions  is  20. 
Listed  also  is  the  maintenance  time  manpower  required  to  accomplish  the  action. 

The  E  task  between  nodes  2  and  3  indicates  the  quantity  of  off-equipment  actions  pertaining  to  the 
part  designated  by  WUC  741 10  or: 

Total  74110  off-equip  action 
Total  on-equip  actions 

The  E  task  shown  between  nodes  2  and  4  relatis  to  the  quantity  of  74110  modules  (2nd  indenture 
recoverabies)  that  are  fault  isolated  and  removed  from  the  aircraft  without  removing  tlte  parent 
assembly.  It  wilt  be  noted  that  if  the  pari  is  removed  on-airc-aft  the  removal  of  the  next  higher 
assembly  is  precluded  by  the  designation  of  an  E  task  (mutually  exclusive). 

The  E  task  between  nodes  3  and  11  relates  to  the  quantity  of  items  that  are  removed  and  bench 
checked  serviceable  or  removed  with  no  repair  required.  Two  conditions  can  result: 

a.  These  are  condidered  to  be  short  turnaround  items  that  do  not  create  a  demand  on  supply 
and  are  not  included  in  the  repair  cycle  time  as  computed  by  the  model. 

b.  Bench  checked  serviceable  and  returned  to  supply  without  maintenance  repair  action 
after  serviceable  part  from  supply  is  placed  on  aircraft.  This  does  not  create  a  demand  on  supply. 


The  E  task  (a  dummy  task  used  for  task  selection  only)  between  nodes  3  and  5  indicates  the  quantity  of 
parts  that  are  time  failures  and  on  which  repair  action  is  required  and  therefore  creates  a  supply 
demand  as  indicated  in  the  Q  task  shown  between  nooes  5  and  12. 
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The  T  task  shown  between  5  and  6  indicates  a  fault  isolation  or  bench  check,  off-equipment,  on  which  a 
repair  action  is  required.  Times  ind  resources  were  not  included  on  this  task  in  initial  data  packages 
but  were  in  subsequent  data  in  order  to  reflect  the  time  on  items  that  are  NRTS  or  condemned.  This 
task  would  generate  the  next  indenture  part. 

The  N  task  shown  between  nodes  6  an  J  13  indicates  the  quantity  of  items  on  which  repair  is  required 
that  are  processed  NRTS  or  are  condemned. 

The  F  task  shown  between  nodes  6  and  7  indicates  the  quantity  of  the  part  repaired  on  base.  Resoirces 
and  times  would  be  shown  on  all  tasks  as  appropriate.  Some  times  are  reflected  on  the  figure. 

The  A  factor  shown  between  nodes  7  and  8  indicate;  the  quantity  of  WUC  7411 A  parts  that  are  fouid 
to  be  involved  in  the  repair  of  WUC  74110  after  it  is  taken  into  the  shop,  as  opposed  to  on-equipment 
fault  isolation  and  removal. 

The  A  factor  shown  between  nodes  4  and  8  indicates  the  quantity  of  WUC  7411 A  parts  that  are  fault 
isolated  and  removed  on-equipment. 

The  tasks  shown  for  WUC  74110  are  duplicates  ol  the  tasks  shown  for  off-equipment  repair  of  WUC 
74110  and  a  similar  explanation  appies,  with  the  exception  of  the  task  shown  between  10  and  16  which 
relates  to  a  repair  processing  time  a",  opposed  to  tlie  actual  time  which  is  shown  under  the  F  task. 

5.  Additional  Applications  and  Nel  work  Techniques 

Experience  gained  diring  netwcrk  development  for  part  application  indicates  that  it  is  feasible  to 
consider  the  application  of  LCOM  to  new  systems  and  apply  the  factor  and  resource  requirements  prior 
to  the  availability  of  actual  usage  data.  However,  additional  work  and  development  of  predictive 
techniques  are  required. 

F.  Some  Special  Problems 

1.  The  Same  Part  Used  in  More  than  One  Location 

Although  this  does  not  impose  a  problem  in  network  developnent,  it  does  require  special  consideration 
in  establishing  a  stock  level  for  the  items  and  assuring  that  the  model  makes  the  correct  *aws  from 
the  supply  accoint  and  returns  the  correct  item  to  the  account  after  repair  has  been  accomplished. 
There  are  a  variety  of  methods  by  which  this  can  be  accomplished,  e.g.,  (4)  the  stock  level  can  be 
divided  between  each  application  and  use  of  the  item;  or,  (2)  all  requirements  can  be  aggregated  under 
a  single  network  branch  w'th  the  A  factor  between  a  W  and  Q/Y  task  reflecting  the  total  off- 
equipment  activity  for  the  items. 

However,  neither  of  the  above  truiy  represents  the  actual  condition.  If  (1)  is  followed,  the  true  stock 
level  required  to  support  all  uses  is  not  represented.  If  (2)  is  followed,  failures  of  the  item  are  equally 
spaced  as  if  it  were  a  single  item  ard  the  possibility  of  queuing  or  simultaneous  failures  is  eliminated. 

The  total  stock  level  is  aggregated  under  a  single  WUC  identification  and  this  WUC  becomes  a 
substitute  resource  for  all  other  applications  of  the  same  item.  To  assire  the  return  of  a  repaired  item 
to  a  single  stock  level  identification  the  network  nodes  should  be  numbered  to  lead  the  supply  demand 
and  off-equipment  repair  effort  to  a  single  node  prior  to  the  consume  and  generate  tasks.  This  node  is 
usually  the  first  time  the  item  appears  in  WUC  sequence. 

2.  Work  Unit  Codes  Reprosenti  tg  More  Than  One  Item  -  Items  Are  Not  Interchangeable 

This  does  not  impose  a  problem  in  network  development;  however,  if  it  is  desired  to  include  repair 
actions  and  supply  demands  specifically  on  these  items,  it  is  necessary  to  consider  them  as  separate 
items  in  the  model. 


To  other  2nd  Indenture 
Recoverable s  as  required 


Figure  10-3  FIRE  CONTROL  SYSTEM  NETWORK 


This  can  be  accomplished  by  assigning  ficticious  cedes  to  each  and  developing  the  networks  for  each. 
For  example:  111DW  might  be  asiipted  codes  110WL  and  11DWR  and  the  proper  item  identification 
made  in  LCOM  Resource  Definition  Forms. 


u 


3.  Actions  on  a  Part  Which  are  Dependent  upon  a  Prior  Action  on  Another  Part 

A  case  in  point  is  the  wheel  and  ‘ire  relationship  wherein  the  wheel  and  tire  are  removed  as  a  unit 
from  the  aircraft  and  subsequent  actions  (supoly  demands  and  maintenance  actions)  on  the  tire  are 
dependent  upon  removal  of  the  tire  in  the  shop. 

In  this  instance,  the  network  can  be  developed  in  such  a  way  that  a  supply  demand  for  a  wheel  also 
generates  a  requirement  for  a  t  re  and  repaired  (or  serviceable)  tires  and  wheels  were  retimed  to  the 
supply  account.  ^ 

* 

4.  Representation  of  Repair  Cycle  Time 

Inasmuch  as  the  time  given  to  the-  repair  (F)  task  in  the  off-equipment  portion  of  the  network 
represents  only  the  time  for  repair,  it  is  necessary  to  provide  for  a  representation  of  the  total  repair 
cycle  time. 

This  can  be  accomplished  by  extending  the  network  after  completion  of  the  F  task  and  inserting  the 
total  time.  However,  when  the  network  includes  2nd  indentire  recoverables,  care  must  be  taken  to 
direct  the  path  for  the  2nd  indenture  recoverable  from  tlie  node  completing  the  F  task  on  the  first 
indenture  item. 

When  2nd  indenture  recoverables  are  shown,  repair  cycle  time  for  the  1st  indentire  item  can  be 
included  by  (1)  establishing  a  dela/  on  the  Q  task  for  the  2nd  indentire  item,  or  (2)  adding  an  overall 
delay  task  lromthe  node  following  the  first  indenture  tasks.  This  method  is  not  the  most  desirable  but 
is  used  in  the  absence  of  detailed  tepair  cycle  data  that  would  permit  more  accurate  jfaphing  of  this 
activity. 

G.  Additional  References  for  Data  Development 

Although  this  chapter  provides  some  insights  into  the  network  development,  it  is  by  no  means 
complete.  The  techniques  described  have  in  some  cases  been  mhanced  and  others  are  no  longer  in 
general  use.  However,  the  techniques  and  examples  do  reflect  the  concern  and  requirement  for 
completeness  of  the  network  and  task  analysis  reouired  when  developing  a  data  base.  A  more  thorough 
and  detailed  discussion  of  this  subject  can  be  foind  in  the  Logistics  Composite  Model  Student  Training 
Text,  July  1977,  developed  at  HQ  TAC. 
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XI.  GENERAL  OPERATING  AND  STUDY  PROCEDURES 

A.  Operating  Procedires 

There  are  a  number  of  steps  which  must  be  taken  to  complete  an  LCOM  II  run  from  beginning  to  end. 
Although  it  is  possible  to  set  up  an  execution  sequence  which  would  accomplish  all  steps  in  one  series 
of  runs,  it  would  be  impractical.  It  is  recommended  that  the  following  initial  steps  be  followed. 

1.  Compilation  and  Assembly 

This  consists  of  translating  four  modules  (Input,  Main,  Restart,  and  Post  Processor)  from  their  source 
language  to  machine  object  code.  The  resulting  object  code  and  the  SIMSCRIPT  II  execution  routines 
must  be  stored  on  files,  henceforth  to  be  referred  to  as  object  files.  This  only  needs  to  be 
accomplished  once  and  thereafter  only  if  the  program  is  changed.  AFMSMET  makes  periodic  releases 
of  the  object  files  on  magnetic  tape  to  Air  Force  users  of  LCOM  II,  therefore  only  the  storage  step  is 
required  by  these  users.  Appendix  A  describes  this  object  release  tape  and  the  specific  instructions  for 
loading  these  files  to  permanent  system  files. 

2.  Data  Storage 

The  data  records  resulting  from  the  input  forms  may  be  considerable  in  number.  Since  card  read-in  is 
slow  at  best  and  hazardous  at  worst,  it  is  recommended  that  the  data  records  also  be  put  on  a  file  or 
tape,  in  card-image  form.  This  can  generally  be  accomplished  with  local  system  software  or  through 
the  use  of  the  LCOM  II  support  program  XFER.  Changes  within  this  data  base  can  then  be  made 
through  system  update  capabilities  or  through  the  use  of  the  XFER  program. 

3.  Program  Executions 

The  execution  sequence  begins  with  the  Input  Module  run.  After  all  data  is  corrected  and  the  Input 
Module  creates  both  an  initialization  and  an  exogenous  file,  the  Main  Module  can  be  executed.  The 
Post  Processor  Module  and  individual  post  processors  can  then  be  executed.  The  Restart  Module  would 
only  be  used  where  necessary  (reference  Chapter  IV,  para  B31).  Appendix  A  contains  the  recommended 
job  control  language  (JCL)  job  streams  for  the  Honeywell,  IBM,  and  CDC  implementations.  Local 
system  differences  may  require  changes  to  this  3CL.  This  appendix  also  includes  a  sample  problem,  its 
run  results,  and  all  necessary  information  to  check  out  an  implementation  of  LCOM  II.  In  addition,  the 
file  structure  and  interfaces  between  the  modules  and  post  processor  are  described. 

Finally,  each  of  the  modules  and  post  processors  require  one  specification  (SPEC)  record  to  be  read 
from  the  card  reader  of  equivalent  file.  This  SPEC  card  is  a  control  record  that  contains  the  user 
defined  input/output  file  requirements  and  assignments.  It  also  permits  the  selection  of  several  run 
options.  See  Chapter  IV  for  details  of  this  SPEC  card. 

B.  Form  Preparation  and  Set-up 

1.  Sequence  Restrictions 

Every  form  is  numbered  according  to  its  use,  as  reflected  in  Table  3-1,  and  are  all  read  by  the  Input  | 
Module.  Form  10  must  be  the  first  form  entered,  Form  13  must  precede  Form  12  if  Form  12A's  are  ! 
used,  and  Forms  17,  21,  22,  and  23  must  follow  in  sequential  order.  No  other  ordering  restriction  j 
exists. 

2.  Preferred  Sequence 

If  the  following  preferred  sequence  is  used,  a  special  feature  of  the  Input  Module  provides  that  not  only 
will  the  normal  diagnostic  messages  be  grouped  at  the  end  of  the  input  processing  listing,  but 
additional  diagnostics  will  be  placed  within  the  listing,  usually  right  after  the  record  in  error.  This 
does  result  in  multiple  diagnostic  references  to  the  same  error,  but  is  extremely  useful.  The  preferred 
sequence  iss  Forms  10,  13,  12,  11,  14,  15,  16,  18,  17,  21,  22,  23  and  20. 
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C.  Deck  Set-up  Pointers 


1.  Input  Module 
Remember  that  in  your  input  deck: 

Form  18  need  not  be  included  in  the  data  deck  if  the  default  values  are  acceptable. 

If  empirical  distributions  are  not  used,  Form  15  need  not  be  included. 

If  no  resources  defined  on  Form  13  are  to  be  on  a  shift,  Form  16  need  not  be  included.  This  is  the  case 
when  no  shifts  are  required. 

If  failure  mechanisms  (failure  parameters  on  Form  13)  are  not  used,  Form  14  need  not  be  included.  A 
warning  diagnostic  will  be  given  in  this  case. 

The  minimum  deck  necessary  to  produce  an  initialization  is  Forms  10,  13,  12,  11,  17  and  21. 

Form  20s  are  normally  run  separately  since  they  are  used  by  the  independent  sortie  generator  to 
produce  the  exogenous  tape.  However,  if  empirical  distributions  are  used  on  Form  20,  Form  15  must 
be  read  with  Form  20. 

The  first  record  in  each  group  of  forms  is  considered  a  header  record  and  all  data  on  the  record  except 
for  the  form  number  itself  is  ignored.  All  other  records  of  the  same  form  number  will  then  follow  this 
record.  Spacing  to  the  top  of  a  new  page  is  automatic  for  each  group.  The  very  last  data  card  must 
have  a  99  in  Columns  2  and  3  to  trigger  final  input  module  processing  and  production  of  the 
initialization  file. 

Column  1  may  be  used  to  space  as  desired  on  an^  data  card.  Refer  to  Chapter  III,  Section  C2.  This 
feature  permits  the  input  processing  printout  to  be  more  user  controlled. 

i 

i  2.  Main  Module 

Since  the  "Change  Card"  method  gives  the  user  quite  a  bit  of  flexibility  to  change  selected  parameters 
without  a  rerun  of  the  Input  Module,  the  following  pointers  are  given  to  facilitate  use  of  this  method. 
Refer  to  Chapter  VII  for  details  about  the  Change  Cards. 

Always  consider  making  minor  changes  to  the  data  base  by  this  method  particularly  in  fine  tiring  a  run 
or  series  of  runs  instead  of  rerunning  the  Input  Module.  When  enough  changes  are  made  here  to 
warrant  cleaning  up  the  Input  Module  data  deck  and  rermning  it,  then  take  the  applicable  diange  cards 
out  and  make  a  corresponding  change  to  the  input  deck.  Recheck  the  initisdization  to  ensire  that  the 
changes  made  were  processed  correctly.  Examples  of  Change  Cards  for  which  this  technique  is 
applicable  are:  AUTH,  CKCNG,  Form  18  Variables,  RCYC,  RFREQ,  SAUTH,  TKCNG,  etc. 

To  properly  sequence  several  different  reports  to  be  printed  at  the  same  time,  modify  the  decimal  part 
of  the  floating  time  field  slightly.  For  example,  request  the  first  report  at  6.0001,  the  second  at 
6.0002,  the  third  at  6.0003,  etc.  This  effectively  prints  all  the  reports  at  time  6.00,  but  in  the 
sequence  desired. 

Make  effective  use  of  the  available  SWICHes.  Control  all  SWICH  settings  through  the  change  card 
file. 

Modify  the  performance  summary  report  frequency  (RFREQ)  and  cycle  (RCYC)  here,  if  required,  even 
though  they  were  originally  preselected  on  Form  10. 
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Make  an  initial  unconstrained  run  against  the  data  base  (initialization  and  exogenous)  by  using  the 
AUTHA  card  with  a  multiplication  factor  of  between  10.0  and  20.0.  What  this  effectively  does  is 
operates  the  simulation  with  "unlimited  resources"  and  will  indicate  any  gross  problems  in  the  package. 
Error  indications  will  generally  show  up  in  the  reports. 

NOTE:  This  AUTHA  card  multiplies  the  resource  authorization  by  the  input  factor,  so  if  any  resource 
is  authorized  at  zero,  it  must  first  be  increased  to  one  or  more  with  an  AUTH  card.  Place  the  AUTHA 
card  just  before  the  STOP  card. 

Change  the  random  seeds  with  the  ISEEO  change  card  for  complementary  runs  leaving  all  other  factors 
constant. 

3.  Post  Processor  Module  and  Post  Processors 

If  any  post  processor  output  is  required,  the  data  must  first  be  requested  in  the  Main  Module  Change 
Card  file,  then  subsequently  the  processing  of  it  must  be  requested  on  the  Transaction  Decoders  SPEC 
card.  This  type  of  implementation  precludes  the  generation  of  large  data  files  which  require  the  use  of 
extra  tapes  diring  processing  and  is  an  aid  to  those  users  who  do  not  require  the  additional  data. 

On  post  processors  with  start  and  stop  times  required  on  the  SPEC  card,  first  verify  that  the  data 
requested  from  the  Main  Module  was  output  for  that  period  of  time  (or  more).  Examples  of  this  are 
GRAPH  and  MATRIX. 

Reference  Chapter  V  for  further  details  on  the  Post  Processor  Module. 

D.  Data  Analysis  Techniques 

Prior  to  processing  a  new  data  base  through  the  Input  Module,  a  plot  of  the  networks  should  be 
thoroughly  reviewed.  See  Figure  9-1  for  example  plot.  This  data  verification  is  a  valuable  step  in  data 
development  and  should  be  considered  a  must.  Obscure  network  logic  errors  often  become  readily 
apparent  when  networks  plots  are  reviewed.  This  plotting  is  generally  accomplished  by  hand  in  the 
development  phase  but  changes  rarely  get  made  to  these  hand  drawn  plots.  Use  of  a  mechanized 
plotting  system  is  recommended.  A  system  is  currently  available  for  Honeywell  computer  installations 
that  have  a  CALCOMP  Plotter. 

The  output  from  the  Input  and  Main  Module  should  be  reviewed  in  detail  to  ensure  validity  and  logical 
results.  3ust  because  an  initialization  tape  is  produced,  there  is  no  guarantee  the  data  is  error  free.  A 
misplaced  decimal  can  change  a  half  hour  task  into  a  3  minute  or  18  second  job.  It  is  obvious  what  a 
crew  size  error  would  do  to  man-hour  consumption. 

Every  warning  and  informational  message  from  the  Input  Module  should  be  checked.  The  Main  Module 
outputs  should  be  used  to  their  maximum  to  ins  ire  that  manning  is  based  upon  logical  and  accirate 
results.  Aircraft  turnaround  time,  man-hours  used,  percent  sortie  accomplishment  are  just  a  few  of 
the  key  statistics  that  should  be  used  to  insure  logical  processing  and  modeling  techniques. 

Other  Main  Module  reports  are  very  helpful.  The  Hit  Matrix  should  be  reviewed  in  detail  to  insure  the 
networks  are  being  entered  the  expected  number  of  times.  BOSTATs  are  essential  to  insure  individual 
work  centers  are  not  creating  bottlenecks  and  back  orders  are  not  accumulating. 

The  work  center  manpower  matrix  indicates  when  the  resoirces  are  demanded  and  where  manpower  is 
being  backordered.  It  also  indicates  how  effectively  the  number  of  crews  in  a  particular  shift  are 
being  used. 

The  initial  Main  Module  unconstrained  run  should  reflect  100%  flying.  The  reason(s)  why  100%  flying 
was  not  reached  must  be  determined.  The  QSTAT  reports  and  Realized  Flying  Schedule  data  should 
provide  this  answer.  Any  corrections  necessary  must  be  made  prior  to  attempting  constrained  runs. 
An  idea  of  what  to  expect  in  man-hours  should  be  compared  with  the  results  of  the  simulation.  The 
output  from  the  Common  Data  Extraction  Program  (CDEP)  and  other  support  programs,  such  as,  the 
Expected  Value  program  may  provide  some  type  of  "bench  mark"  to  aid  in  interpreting  results. 
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All  of  the  above  should  be  accomplished  prior  to  attempting  constrained  runs.  These  preliminary 
analysis  techniques  help  ensure  that  unexplained  problems  won't  be  encountered  during  the  resource 
constraining  process  and  therefore  that  model  reaction  is  to  the  constraining  process  alone  rather  than 
to  other  undetected  problems. 

The  constrained  runs  analysis  of  the  aircraft  configuration  report,  QSTAT  will  aid  in  determining  if 
there  are  any  unusual  conditions  occurring  within  the  simulations  with  respect  to  configuration 
management.  These  QSTAT  reports  are  also  helpful  when  analyzing  unconstrained  runs. 

The  Realized  Flying  Schedule  data  and  Mission  Post  Processor  results  should  be  used  to  verify  that 
sorties  lost  are  due  to  maintenance  non-delivery  and  not  because  of  poor  scheduling  of  the  flying 
program.  Sorties  can  be  scheduled  in  such  a  manner  that  they  have  no  possibility  of  being 
accomplished. 

The  analysis  and  data  verification  techniques  that  have  been  described  are  by  no  means  complete  but 
can  serve  as  a  guide  toward  better  simulation  analysis. 
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APPENDIX  A 


STANDARD  SYSTEM  RELEASE 

I.  PURPOSE 

To  provide  a  complete  description  of  the  standard  system  release  tape,  implementation  procedures,  job 
control  language,  and  implementation  test  run  results. 

n.  scope 


The  remainder  of  this  section  will  include  the  description  of  the  appropriate  Honeywell,  CDC,  or  IBM 
implementation  release.  The  first  line  printed  on  all  runs  will  indicate  the  computer  (HIS,  CDC,  or 
IBM)  and  the  LCOM  II  version  number.  This  version  number  will  of  the  form  "X.Y.Z",  where  for  this 
release  X  will  always  be  3  and  Y  will  always  be  5.  The  .Z  is  for  internal  AFMSMET  use  and  may  be 
blank  or  contain  a  number  from  1  to  9.  The  .Z  is  to  ensure  corrections  between  releases  can  be 
tracked  for  debugging  purposes. 

m.  CAUTION 

With  each  new  system  release,  it  will  be  necessary  to  load  and  check  out  the  entire  system,  i.e., 
execute  all  runs.  Data  interfaces  between  the  runs  will  not  always  be  compatible  across  different 
versions. 

IV.  STANDARD  SYSTEMS  RELEASE  (HONEYWELL) 

Version  3.5E,  dated  12  October  1979  is  the  systems  release  herein  described. 

A.  Systems  Release  Tape 

The  seven  track  tape  produced  for  the  LCOM  II  Systems  Release  contains  all  the  necessary  program 
and  data  files  for  system  implementation  and  initial  check  out  with  sample  Problem  f/3.5.  In  the 
following  write-up,  ail  names  for  PRMFL's  and/or  tapes  are  recommended  names,  used  for  consistency 
of  description.  PRMFL  sizes  given  are  minimum  sizes  required  for  the  initial  checkout. 

B.  Release  Tape  File  Description. 


PRMFL 

PRMFL 

± 

Description 

Name 

Size  (LLINK) 

I 

Simulation  Module  Binaries  (production 
version) 

MAINCSTR 

320 

2 

Simulation  Module  Binaries  (debug  version) 

MAINDBUG 

366 

3 

Decoder  Binaries 

DCDRCSTR 

47 

4 

Parts  Post  Processor  Sort  Binaries 

PRTSSORT 

1 

5 

Parts  Post  Processor  Binaries 

PRTSCSTR 

16 

6 

Manpower  Matrix  P.P.  Sort  Binaries 

MTRXSORT 

1 

7 

Manpower  Matrix  P.P.  Binaries 

MTRXCSTR 

82 

8 

Graph  Post  Processor  Binaries 

GRPHCSTR 

20 

9 

Display  Post  Processor  Binaries 

DSPLCSTR 

12 

10 

Mission  Post  Processor  Binaries 

MSNCSTR 

59 

11 

Support  Equipment  Sort  Binaries 

SEQSORT 

1 

12 

Support  Equipment  PP  Binaries 

SEQCSTR 

20 

13 

Sample  Problem  //3.5 

SAMPPROB 

21 

14 

Change  Card  File  (Unconstrained  Run) 

CHNG.UNC 

5 

15 

Change  Card  File  (Constrained  Run) 

CHNG.CON 

5 

16 

Restart  Program  Binaries 

RESTCSTR 

3 

17 

Input  Module  HSTAR  File  (Overlay  Binaries) 

A-2 

INPTHSTR 

156R 

C.  Additional  PRMFL's  Needed  to  Make  Fall  Systems  Test. 


File  Name 

Description 

Size 

Type  Data 

EXOG.60D 

60  Day  Exogenous  File 

92 

BCD 

INIT.  3.5 

Sample  Problem  Initialization  File 

12 

BIN 

GRPH.OUT 

Graph  Data  Produced  by  SIMRUN/DECODER 

14 

BIN 

PRTSDICT 

Parts  Dictionary  Produced  by  SIMRUN/DECODER 

1 

BIN 

MTRXDICT 

MTRX  Dictionary  Produced  by  SIMRUN/DECODER 

1 

BIN 

DSPL.OUT 

Display  Data  Produced  by  SIMRUN/DECODER 

8 

BIN 

Additional  PRMFL's/Tapes  Required. 

Name 

Description 

Type  Data 

U.SIMOUT 

Integrated  SIMRUN  Unconstrained  P.P.  output 

BIN 

C.SIMOUT 

Integrated  SIMRUN  constrained  P.P.  output 

BIN 

I.SIMOUT 

Initialization  Data  for  SIMRUN 

BCD 

LCOMDUMP 

Dump/Restart  File  (must  be  a  tape) 

BIN 

PRTS.BCD 

Output  of  DECODER  for  PARTS  SORT 

BCD 

PRTS.OUT 

PRTS.BCD  File  Sorted 

BCD 

MTRX.BCD 

Output  of  DECODER  for  MTRX  SORT 

BCD 

MTRX.OUT 

MTRX.BCD  File  Sorted 

BCD 

RFS.DATA 

Realized  Flying  Schedule  output  from  DECODER 

3CD 

SEQ.DATA 

Support  Equipment  Date  output  from  DECODER 

BCD 

SEQ.OUT 

SEQ.DATA  File  sorted 

BCD 

E.  Run  Control  Cards. 


1.  Job  control  language  (Control  Cards)  necessary  to  copy  the  LCOM  II  system  release  tape  to 
PRMFLs  and  conduct  test  run  are  described  below  and  are  included  in  table  A-l.  Figure  A- 1  contains 
charts  showing  the  interfaces  between  runs  3  thru  11.  File/Tape  names  within  these  listings  and  charts 
make  reference  to  the  same  file  names  specified  in  para  B,  C,  and  D  above. 

Run  //  Description 

1  Utility  Program  to  copy  17  LCOM  II  system  PRMFLs  to  the  Systems  Release  tape. 

2  Utility  Program  to  copy  17  tape  files  to  PRMFL's. 

3  Input  Module  Run  of  provided  Sample  Problem. 

4  Main  SIMRUN  (Unconstrained)  using  Data  from  Run  3. 

4R  Main  SIMRUN  Restart  (from  memory  dumps). 

5  Decoder  Run  using  data  from  Run  4. 

6  Parts  Post  processor  run  using  data  from  Run  5. 

8  Graph  Post  processor  run  using  data  from  Run  5. 

7  Manpower  Matrix  Post  processor  run  using  data  from  Run  5. 

9  Display  Post  Processor  Run  using  data  from  Run  5. 

10  Mission  Post  Processor  Run  using  data  from  Run  5. 

11  Support  Equipment  Post  Processor  Run  using  data  from  Run  5. 

2.  Note:  The  Input  Module  Run,  Run  //3,  is  processing  this  test  case's  Initialization  Process 
and  Sortie  Generation  Process  together.  However,  with  large  data  bases  these  processes  are  normally 
run  separately  using  appropriate  null  files.  There  is  an  extra  PRMFL  and  tape  card  on  the  Run  //4  3CL 
after  the  ENDJOB  card.  If  these  are  suostituted  for  the  equivalent  PRMFL  11  and  tape  04  cards  in 
the  run,  the  constrained  sample  problem  can  be  executed.  By  using  the  C.SIMOUT  tape  as  input  on 

unit  1  of  run  5,  runs  5,  6,  7,  8,  9,  10,  and  11  can  then  follow  the  SIMRUN  as  before.  Also,  there  are 
additional  exchange  cards  to  make  the  SIMRUN  take  memory  dump  checkpoints  for  restart  purposes. 
Substitutions  to  satisfy  your  own  computer  system's  requirements  may  also  be  required. 
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3.  Caution;  All  jobs  submitted  thru  CARDIN  require  the  use  of  the  STRIP  option,  i.e.  no 
sequence  numbers  or  data  can  be  in  columns  73-80. 

F.  Description  of  Test  Run  Results  (for  checkout  purposes) 

1.  Run  #1  -  System  copy  to  tape  -  Performed  by  AFMSMET  only. 

2.  Run  »2  -  UTILITY  (Tape  to  PRMFL)  -  Users  initial  run.  See  Figure  A-2  for  UTILITY  copy 
results. 


3.  Run  #3  -  Input  Module. 

a.  Legal  warning  and  information  messages  wiil  be  found  throughout  the  listing.  The 
message  //  and  quantity  found  are  as  follows  (///Qty);  41/1,  144/7,  140/1,  20/1,  67/1,  16/1  ,  17/1,  24/1 
(NONE),  36/1  (NONE),  11/1  (NONE),  96/1  (7  entries),  97/1  (NONE),  79/1  (NONE),  80/1  (NONE),  4/1  (1 
entry),  146/1  (NONE),  147/1  (NONE),  117/1  (NONE),  31/1  (1  entry),  and  53/1.  Also,  with  SPEC  card 
option  INFO=3,  the  node  range  report  (MSG  17)  will  be  printed  in  full. 

b.  Total  sorties  generated,  by  mission  type  (report); 


MS  NAM 

NO  MSN 

NO  SORT 

FLY  HF 

PREFLT 

60 

60 

0.0 

RECON 

420 

600 

479.999 

1NTRD1 

120 

240 

363.315 

CLSPT1 

60 

180 

137.919 

CLSPT2 

60 

240 

346.120 

INTRD2 

60 

120 

183.858 

INTRD3 

60 

60 

60.0 

FERRY1 

60 

60 

119.923 

FERRY2 

60 

120 

232.238 

Input  Data  Summary  (report); 


Qty 

23 

96 

130 

163 

11 

9 

3 

6 

9 

13 

70 

9 

1 

2 

2 

9 

3 

10 

10 

2 


Descriptor 

Resources 

Task  Names 

Node  Names 

Control  Table  Entries 

Failure  Clocks 

Mission  Entry  Points  (IETB) 

Resources  Entering  Network  (NACO) 

Total  //  of  Configurations  Defined  (AJ1  A/C)  (NCRS) 
Search  Patterns  (NSR.PT) 

Next  Higher  Failures  (NNHF) 

Task  Resource  Requirements  (TRR) 

Unique  Groups  of  Clock  Decrements  (NOCL) 

Unique  Pieces  of  Internal  Equipment  (EQUIP) 
Internal  Equipment  Groups  (ILIST) 

Triggering  Events  (NTEVT.DV) 

Operations  Headings  on  Form  10 
Aircraft  Headings  on  Form  10 
Personnel  Headings  on  Form  10 
Part  Headings  on  Form  10 
AGE  Headings  on  Form  10 


d.  To  ensure  full  preparation  of  an  initialization  file,  two  messages  must  follow  the 
printing  of  the  dictionaries.  These  messages  are  as  follows  and  may  be  followed  by  a  printout  of  the 
entire  initialization  file  data  and  an  additional  message  "LEGITIMATE  END  MARKER  READ". 

.  MAIN  MODEL  INIT  FILE  IS  TO  BE  PRODUCED. 

.  LEGITIMATE  END  MARKER  WRITTEN 

4.  Run  //4  -  Main  Module  Run  (Unconstrained): 

This  new  sample  problem  //3.5  does  not  provide  a  fully  unconstrained  run.  The  pre-sortie  time  line  for 
internal  reconfigurations  requires  adjustment  to  permit  an  unconstrained  100%  flying  support.  It  is 
expected  that  future  versions  of  this  sample  problem  will  again  produce  truly  unconstrained  run 
results. 


a.  Unconstrained  Run 


(1)  From  the  Level  II  day  10-60  Performance  Summary  Report,  the  following  selected 
statistics/total  values  are  given: 

£ 

Statistics 

Value 

3 

Percent  accomplished 

100.00 

8 

Percent  accomplished 

99.48 

n 

No.  of  Attritions 

2.00 

T5 

No.  of  RAM  Repairs 

2.00 

23 

Avg  No.  of  Sorties  /  A/C  /  Day 

1.33 

24 

Flying  Hours 

1603.63 

33 

No.  of  men  demanded 

32235.00 

40 

Simulated  MH  Per  Flying  Hr 

11.67 

44 

No.  of  reparables  generated 

6544.00 

57 

No.  of  units  demanded 

6715.00 

75 

No.  of  units  demanded 

1069.00 

(2) 

From  the  end  of  run  Stop  (or  Memory  Saved)  Report  at  time  100.01:  total  jobs 

started  =  57050,  jobs  completed  =  57050,  and  jobs  preempted 

b.  Constrained  Run 

=  0. 

(1)  From  the  Level  II  day  10-60  Performance  Summary  Report,  the  following 

selected  statistics/total  values  are  given: 

£ 

Statistics 

Value 

3 

Percent  accomplished 

90.92 

8 

Percent  accomplished 

89.17 

T4 

No.  of  Attritions 

4.00 

T5 

No.  of  RAM  repairs 

1.00 

23 

Avg  No.  of  Sorties/  A/C  /  Day 

1.25 

24 

Flying  Hours 

1417.26 

33 

No.  of  men  demanded 

29548.00 

40 

Simulated  MH  Per  Flying  Hour 

12.32 

44 

No.  of  reparables  generated 

6178.00 

57 

No.  of  units  demanded 

6232.00 

62 

No.  of  cannibal izations 

2.00 

75 

No.  of  units  demanded 

984.00 

(2) 

From  the  eno  of  run  Stop  (or  Memory 
completed  =  53015,  and  jobs  preempted 

A-S 

S^ed)  Report  at  time  100.01;  total  jobs 

started  =  53061,  jobs 

5.  Run  # 5  Decoder  Run  (Unconstrained):  A  two  page  report  is  printed  as  shown  in  Figure 
A-3.  For  runs  5-10,  no  constrained  run  results  will  be  given. 

6.  Run  #6  Parts  Sort  and  Parts  Post  Processor  (Unconstrained). 

a.  Parts  Sort  Records  Input  r  11773,  Records  output  =  11773. 

b.  See  Figure  A-4  for  run  results. 

7.  Run  #7  GRAPH  POST  Processor.  (Unconstrained) 

a.  See  Figure  A-5  for  statistic  value  printouts. 

b.  See  Figure  A-6  for  Histogram  of  post  sortie  A/C  turnaround  times. 

c.  See  Figure  A-7  for  graph  of  Stat  22  (Avg  AC  Post- Sortie  Time  (Hrs). 

8.  Run  //8  Matrix  Sort  and  Matrix  Post  Processor  (Unconstrained). 

a.  MTRX  SORT  -  Records  Input  =  93070.  Records  Output  =  93070. 

b.  See  Figure  A-8  for  one  set  of  matrices  (two  parts)  printed  in  the  run. 

9.  Run  #9  Display  Post  Processor  (Uncon).  See  Figure  A-9  for  the  first  full  display  of  each 
aircraft  (Day  0  and  Day  16). 

10.  Run  // 1 0  Mission  Post  Processor  (Uncon).  See  Figure  A-10  for  the  final  Level  3  Mission 

Success  Statistics  Summary  Report. 

11.  Run  # 1 1  Support  Equipment  Post  Processor  (Uncon).  See  Figures  A- 1 1  and  A-12  for  the 
model  and  actual  on-equipment  demands  for  the  resource  called  truck  in  the  sample  problem. 

G.  S1MSCR1PT  U  Systems  Release 

All  installations  using  LCOM  II  are  responsible  for  obtaining  their  own  SIMSCRIPT  II. 5  compiler  main¬ 
tenance.  AFMSMET  has  taken  extreme  care  in  attempting  to  provide  an  LCOM  II  model  that  would 
run  on  the  Final  Air  Force  release  //1 2.  However,  latent  errors  found  in  release  #12  make  a  subsequent 
release  under  a  GSA  maintenance  contract  a  preferable  compiler  for  use  with  the  LCOM  II  system. 
AFMSMET  can  provide  absolute  files  (HSTARs)  to  those  Air  Force  installations  where  there  is  no 
compiler  maintenance  contract.  However,  the  user  is  responsible  for  ensuring  that  the  GCOS  software 
at  his  computer  installation  is  compatible  with  the  standard  GCOS  software  release  in  use  by  the 
CREATE  system  at  Wright-Patterson  Air  Force  Base,  Ohio.  Any  computer  system  software 
differences  that  prevent  the  SIMSCRIPT  II  execution  library  from  functioning  will  preclude 
AFMSMET's  support  to  such  installations. 

H.  System  Improvements 

LCOM  II  Version  3.5E  only  enhances  its  prodecessor  Version  3.5.  The  significant  differences  include 
the  addition  of  the  Support  Equipment  Post  Processor,  two  new  PSR  statistics,  and  a  fix  to  the  canni¬ 
balization  feature  in  the  Main  module  to  better  handle  multiple  backordered  demands  for  the  same 
part.  The  difference  between  Version  3.5E  and  Version  2.0  are  as  follows: 

l.  System  Standardization 

The  LCOM  II  system  has  been  standardized  across  four  computers  upon  which  it  has  been  implemented. 
These  computers  are  the  Honeywell  600/6000,  CDC  6600/7600,  CDC  6600/7600  with  extended  core 
storage  (ECS)  and  the  ITEL  AS/5  (IBM  S360  compatible). 


This  standardization  involves  the  following: 
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a.  Input  Module  -  PREAMBLE  is  different  on  all  computers  -  remainder  of  source  code  is 

identical. 


b.  Main  Module  -  PREAMBLE  is  different  on  all  computers  -  remainder  of  source  code  is 
identical  except  for  the  Dump/Restart  capability  on  Honeywell.  However,  the  PREAMBLES  for  the 
CDC  and  CDC  with  ECS  are  identical  except  for  the  few  lines  of  code  necessary  to  handle  the  ECS 
operations.. 


c.  Post  Processor  Module  -  ail  programs  are  identical  on  all  computers,  both  the  PRE¬ 
AMBLES  and  sources. 

2.  System  Efficiency  and  memory  requirements 

The  Main  Module  has  been  improved  in  both  run  time  efficiency  and  memory  requirements  over  that 
required  for  Version  2.0.  A  run  time  savings  (per  run)  of  20%  or  more  and  a  memory  savings  of 
approximately  8K  has  been  obtained.  The  run  time  saving  is  dependent  upon  which  computer  is  being 
used  and  also  on  the  data  base  construction.  However  it  should  be  no  less  than  20%.  This  savings 
comes  primarily  from  the  elimination  of  a  detailed  programmer  debug  feature  that  in  most  cases  is  no 
longer  needed  due  to  the  stability  of  LCOM  II  over  the  past  year  and  diring  Version  3.5  testing. 

Both  a  PRODUCTION  (streamlined)  and  DEBUG  version  are  being  provided  in  this  release  so  users  will 
have  the  Debug  version  as  backup. 

3.  User  Documentation 

This  user  reference  guide  is  entirely  compatible  with  Version  3.5E.  Reference  to  all  previous  LCOM  I 
and  LCOM  II  user  docun  uration  should  be  discontinued.  Also,  the  improved  LCOM  II  system  termi¬ 
nology  will  help  avoid  future  conflicts  in  references  to  the  software  and  data  bases. 

4.  System  Compatability 

Users  of  Version  2.0  will  have  full  upward  compatability  of  their  data  bases  except  that  general  sub¬ 
stitution  must  be  indicated  in  the  "C"  column  Form  12  to  activate  the  general  substitutions  specified 
on  the  Form  13's.  All  new  capabilities,  and  features  are  user  selectable  or  automatic,  requiring  either 
no  or  some  additional  data. 

5.  New  Capabilities  and  Features 

a.  Generalized  Resource  Substitution  for  use  with  a  POMO  (AFR  66-5)  type 
organizational  structure. 

b.  Task  specific  Resource  Substitution  for  use  with  POMO  (AFR  66-5)  also. 

c.  Integration  of  the  PRE-Matrix  Program  into  the  DECODER. 

d.  User  control  of  spare  aircraft  assignment. 

e.  Time  controlled  activity  processing,  i.e.,  the  ability  to  cancel  an  activity  not  started. 

f.  Making  the  Form  17  PRE  and  POST  sortie/activity  configuration  fields  accept  a  blank 
(don't  change  configuration  policy). 

g.  Task  substitution  on  a  calendar  bases. 


h.  Ability  to  change  the  A,  E,  and  G  probabilities  diring  simulation. 

i.  Multiple  HIT  MATRIX  reports. 


aircraft  configuration  ex*erna*  contro^  AIR  ABORTS  and  their  resultant  network  processing  and 
k.  Extra  edits  on  Form  21. 

J.  Many  CHANGE  cards  can  now  be  used  at  simulation  time  greater  than  zero. 

m.  Special  plugged  aircraft  logic  prior  to  mission  cancellation. 

n.  User  selected  aircraft  tracking  with  the  DISPLAY  post  processor. 

o.  An  expanded  NODE  usage  report  with  many  additional  data  edits  and  network  devel¬ 
opment  aids. 

p.  Additional  cannibalization  task  edits. 


q.  Improved  user  information  of  the  aircraft  assignment  process  with  an  expanded 
message  510  in  the  main  module. 

r.  A  full  pass  thru  the  CHANGE  cards  prior  to  an  abort. 

s.  Elimination/automation  of  some  CHANGE  cards. 

t.  Addition  of  the  U  selection  mode. 

u.  Aircraft  Displays  now  print  the  aircraft  tail  numbers. 

v.  Correction  of  the  exponential  distribution's  use  of  the  threshold  constant. 

d  „w*  u-  Additiori  of  several  new  reports.  (Node  Usage  Report  Part  II,  Circular  Substitution, 

Resource  Combination  Sets,  and  the  Aircraft  Tail  Number  Identity  Dictionary.) 

x.  Addition  of  a  new  post  processor  -  the  Support  Equipment  Post  Processor. 

Minor  Enhancements  and  Problem  Corrections 

a.  Many  new  edits  associated  with  the  above  features  have  been  added. 

.b*  Report  78-5  has  marking  along  the  edge  of  the  page  to  indicate  the  differences  (addi¬ 
tions/ deletions/ corrections)  between  it  and  Report  78-1. 

c-  The  cannibalization  feature  in  the  Main  Module  has  been  modified  to  take  care  of  multi¬ 
ple  backordered  demands  for  the  same  part  on  the  same  AC.  Version  3.5  would  go  to  end  of  network  if 
a  demand  for  a  part  on  an  AC  occurred  and  a  demand  for  that  part  had  already  been  backordered.  Of 
coirse,  cannibalization  still  cannot  occur  until  all  demands  except  for  one  for  a  single  part  have  been 
satisfied  by  means  other  than  cannibalization. 

!•  Error  Corrections  (from  previous  versions).  -  Included  in  above. 

Known  Errors  -  Reported  with  release  tape  letter. 


Table  A-l  Honeywell  Release  3.5E  Runs  -  3CL 


IDENT 

NOTE 

NOTE 

USERID 

UTILITY 

QUTIL 

FUTIL 

FUTIL 

FUTIL 

FUTIL 

FUTIL 

FUTIL 

FUTIL 

FUTIL 

FUTIL 

FUTIL 

FUTIL 

FUTIL 

FUTIL 

FUTIL 

FUTIL 

FUTIL 

PRMFL 

PRMFL 

PRMFL 

PRMFL 

PRMFL 

PRMFL 

PRMFL 

PRMFL 

PRMFL 

PRMFL 

PRMFL 

PRMFL 

PRMFL 

PRMFL 

PRMFL 

PRMFL 

TAPE 

END30B 


WP1355.MSMET  SYS  REL  RUN  2 

***  UTILITY  3 CL  TO  COPY  16  TAPE  FILES  TO  DISK  *** 
***  FILE  NAME  IS  SR.RUN2  *** 

LCOM.II$XXXXXX 

EOF/ALL 

TP,  AA, COPY/IF/, SKIP/IF/, HOLD/TP/ 
TP,AE,COPY/lF/,HOLD/TP/ 

TP, AF, COPY/IF/, HOLD/TP/ 

TP, AG, COPY/IF/, HOLD/TP/ 

TP, AH, COPY/IF/, HOLD/TP/ 

TP, AI, COPY/IF/, HOLD/TP/ 

TP, A3, COPY/IF/, HOLD/TP/ 

TP,  AK, COPY/IF/, HOLD/TP/ 

TP, AL, COPY/IF/, HOLD/TP/ 

TP,  SS,COPY/ IF/, HOLD/TP/ 

TP, SE, COPY/ IF/, HOLD/TP/ 

TP,  SP,  COPY/IF/,  HOLD/TP/ 

TP^CU, COPY/1  F/, HOLD/TP/ 

TP, CC, COPY/ 1 F/, HOLD/TP/ 

TP, RS, COPY/ 1 F/, HOLD/TP/ 

TP,IH,RREST/1F/,RWD/TP/ 

A  A,  W,L,  LCOM.il/V3. 0/M  AINCSTR 

AE, W,L,LCOM.II/V3.0/DCDRCSTR 

AF, W,L,LCOM.II/V3.0/PRTSSORT 

AG, W,L,LCOM.II/V3.0/PRTSCSTR 

AH, W,L,LCOM.II/V3.0/MTRXSORT 

AI, W,L,LCOM.II/V3.0/MTRXCSTR 
A3,W,L,LCOM.II/V3.0/GRPHCSTR 

AK, W,L,LCOM.II/V3.0/DSPLCSTR 

AL, W,L,LCOM.II/V3.0/MSNCSTR 
SS,W,L,LCOM.II/V3.0/SEQSORT 
SE,  W,L,  LCOM.il/V3. 0/S  EQCSTR 
SP,W,L, LCOM.il/V3. 0/S  AMPPROB 
CU,W,L,LCOM.II/V3.0/CHNG.UNC 
CC,W,L,LCOM.II/V3.0/CHNG.CON 
RS,W,L,LCOM.II/V3.0/RESTCSTR 
IH,W,R,LCOM.II/V3.0/INPTHSTR 
TP,X  1DD,,XXXXX„SR.V3./5E 


SPEC 


$ 

SPEC 

$ 


IDENT 

* 

USERID 

PROGRAM 

PRMFL 

LIMITS 

FFILE 

PRMFL 

FFILE 

PRMFL 

PRMFL 

PRMFL 

INFO=3  FOR  Mr  10 
END30B 


INFO=3  FOR  M=  10 
PRMFL 


WP1355.MSMET  LCOM  INPUT  MODULE  -  RUN  3 

****input  module  run  of  provided  sample  problem**** 

LCOM.II$XXXXXX 

RLHS 

H*,E,R,LCOM.II/V3.0/INPTHSTR 
1 5,32K„5K 
07  NOSLEW 

07|r/W,S,LCOM.II/V3.0/INIT.SP 
09  NOSLEW 

09|w,S,LCOM.II/V3.0/EXOG.60D 
17,R,S,CACI/SIMERR 
1 0,R,S,LCOM.II/V3.0/SAMPPROB 
EXOG=9 

****EXCHANGE  <5c  EXTRA  CARD  FOR  ABOVE  RUN  TO 
REDIRECT  ALL  PRINT  TO  UNIT  15**** 

PRNT=15 

1 5, W,L, LCOM.il/V3. 0/PRNTFILE 
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1 

1 

Table  A-l  cont. 

$ 

IDENT 

WPI355,MSMET  MAIN  SIMRUN  -  RUN4U 

$ 

* 

****MAIN  SIMRUN  (UNCON)  USING  RUN  3  DATA  **** 

$ 

USERID 

LCOM.II$XXXXXX 

$ 

LIMITS 

,„15K 

$ 

LOWLOAD 

$ 

OPTION 

FORTRAN.GO 

$ 

LIBRARY 

SL 

$ 

SELECT 

LCOM.il/V3. 0/MAINCSTR 

$ 

EXECUTE 

$ 

LIMITS 

85,87K,-3K,15K 

$ 

FFILE 

04, NOSLEW 

$ 

TAPE 

04,X4DD„XXXXX„U.SIMOUT/RNG 

$ 

FILE 

08,X8R 

$ 

FFILE 

07, NOSLEW  1 

$ 

PRMFL 

07, R,L, LCOM.il/V3. 0/INIT.SP 

$ 

PRMFL 

09,W,L,LCOM.II/V3.0/I.SIMOUT 

$ 

PRMFL 

1 0,R,L,LCOM.II/V3.0/EXOG.60D 

$ 

PRMFL 

SL,R,S,CACI/SIM2LIB 

$ 

PRMFL 

17,R,S,CACi/SIMERR 

$ 

DATA 

11 

$ 

SELECT 

LCOM.il/V3. 0/CHNG.UNC 

$ 

DATA 

05 

SPEC 

CHNG=1 1  DATA 

=09  EXOG=10 

$ 

END30B 

$  *  **EXCHANGE  CARDS  TO  MAKE  ABOVE  RUN  CONSTRAINED** 

$  SELECT  LCOM.II/V3.0/CHNG.CON 

$  TAPE  04,X4DD„XXXXX„C.SIMOUT/RNG 

$  *  **EXCHANGE  CARDS  TO  TAKE  MEMORY  DUMPS** 

$  TAPE  08,X8D„XXXXX„LCOMDUMP/RNG 

SPEC  CHNG=1 1  DATA=09  DUMP=08  EXOG=IO 


$  IDENT  XXXXXX.MSMET  -  MAIN  SIMRUN  RESTART  -  RUN  4R 

******  ALL  3CL  IS  IDENTICAL  TO  RUN  4  JCL  (WITH  THE 

MEMORY  DUMP  EXCHANGE  CARDS)  EXCEPT  FOR: 

(1)  SUBSTITUTE 

$  SELECT  LCOM.II/V3.0/RESTCSTR 

FOR 

$  SELECT  LCO  M  .II/V3. 0/M  AIN  CSTR 

(2)  SUBSTITUTE  SPEC  CARD 

SPEC  REST=8  CHEK=5 

(3)  ADD  CHANGE  CARDS  (SEE  WRITE-UP  FOR  FORMAT) 

RUN  RESTOl 

RECRD  7  5.0  8 

PSROUT  27.0 

G  6,G  2,G  4,G  5, 29, 39, 32  * 

PSROUT  49.0 

1,13,27,40,48,58,67  * 

PSROUT  59.0 

ALL  * 

STOP  60.0 

AFTER 

$  SELECT  LCOM.II/V3.0/CHNG.UNC 
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Table  A-l  cont 


IDENT 

WP1355.MSMET  RUN  5 

* 

****DECODER  RUN  USING  RUN  4  DATA  **** 

USERID 

LCOM.II$XXXXXX 

LOWLOAD 

OPTION 

FORTRAN, NOMAP 

LIBRARY 

SL 

SELECT 

LCOM.II/V3.0/DCDRCSTR 

EXECUTE 

DUMP 

LIMITS 

15,20K„10K 

PRMFL 

SL,R,S,CACI/SIM2LIB 

PRMFL 

17,R,S,CACI/SIMERR 

DATA 

05 

RPD=9  PRTS=10 

MTRX=1 3  DPLY=12 

R.FS=1 1  DBUG=0 

* 

FFILE 

12, NOSLEW 

PRMFL 

1 2,  W,S, LCOM.II/V3,.0/DSPL.OUT 

TAPE 

01,X2DD„XXXXX„U.SIMOUT 

FFILE 

09, NOSLEW 

PRMFL 

09, W,S, LCOM.il/V3. 0/GRPH.OUT 

FFILE 

10, NOSLEW 

PRMFL 

1 0,  W ,  S,  L  CO  M  .11  /V  3. 0/P  RTSDI CT 

FFILE 

14,  NOS  LEW 

TAPE 

1 4, X3D„XXXXX„PRTS.  BCD/RING 

PRMFL 

1 3,W,S,LCOM.II/V3.0/MTRXDICT 

FFILE 

13, NOSLEW 

FFILE 

15, NOSLEW 

TAPE 

1 5, X4D„XXXXX„MTRX. BCD/RING 

FFILE 

11, NOSLEW 

TAPE 

1 1,X  1 1DD„XXXXX„RFS.DATA/RNG 

FFILE 

08, NOSLEW 

TAPE 

08,X8DD„XXXXX„SEQ.DATA/RNG 

ENDJOB 

IDENT 

WP1355,MSMET  RUN  6 

* 

****PARTS  POST  PROCESSOR  USING  RUN  5  DATA 

USERID 

LCOM.II$XXXXXX 

LIMITS 

15 

LOWLOAD 

SELECT 

LCOM.II/V.3.0/PRTSSORT 

EXECUTE 

LIMITS 

l5,16K„1000 

TAPE 

SA,X4D„XXXXX„PRTS.BCD 

TAPE 

SA,X5C„XXXXX„PRTS.OUT/RNG 

FILE 

S1,A1,50R 

FILE 

S2,A2,50R 

FILE 

S3,A3,50R 

LOWLOAD 

OPTION 

FORTRAN, NOMAP 

LIBRARY 

SL 

SELECT 

LCOM.II/V3.0/PRT5CSTR 

EXECUTE 

LIMITS 

5, 14K„2K 

PRMFL 

SL,R,S,CACI/SIM2LIB 

PRMFL 

17,R,S,CACI/SIMERR 

DATA 

05 

DAYS=60 

PRMFL 

01,R,S,LCOM.II/V3.0/PRTSD3CT 

TAPE 

02,X5DD„XXXXX„PRTS.OUT 

END JOB 

A- 11 

SPEC 


Table  A-l  cont. 


$  1DENT 

$  * 

$  USERID 

$  LIMITS 

$  * 

$  SELECT 

$  EXECUTE 

$  LIMITS 

$  TAPE 

$  TAPE 

$  FILE 

$  FILE 

$  FILE 

$  * 

$  LOWLOAD 

$  OPTION 

$  LIBRARY 

$  SELECT 

$  EXECUTE 

$  LIMITS 

$  PRMFL 

$  PRMFL 

$  PRMFL 

$  TAPE 

$  DATA 

SPEC  DICT=1  IN=2  NUM 
NBLK=2  BLK1=5  BLK2=2 
CREWCH 125300081 6 
CREWCH2253000816 
OMPERS1 25300081 6 
OMPERS225300081 6 
FLTENG 125300081 6 
FLTENG225300081 6 
HYDTEC1253000816 
HYDTEC225300081 6 
HYDSPLI 25300081 6 
HYDSPL225300081 6 
COMTEC1 25300081 6 
COMTEC225300081 6 
COMSPL1 25300081 6 
COMSPL225300081 6 
MUNSPL1 253051 321 
MUNSPL2253051 422 
CAMTEC1253051 422 
CAMTEC2253051 422 
$  ENDJOB 


WP1355,MSMET  RUN  8 

♦♦MATRIX  POST  PROCESSOR  USING  RUN  5 
LCOM.II$XXXXXX 

50, „10K 

♦  MATRIX  SORT  * 

LCOM.II/V3.0/MTRXSORT 

1 5, 30K 

SA,X9DD„XXXXX„MTRX.BCD 

SZ,A5S„XXXXX„MTRX.OUT/RNG 

51, A1,100R 

52, A2, 100R 

53, A3, 100R 

*  MATRIX  PROGRAM  * 

FORTRAN, NOMAP 
SL 

LCOM.II/V3.0/MTRXCSTR 

30,30K„10K 

SL,R,S,CACI/SIM2LIB 

17,R,S,CACI/SIMERR 

01,R,S,LCOM.II/V3.0/MTRXDICT 

02,A5DD 

05 

=9  STRT=10  STOP=60 
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Table  A-l  cont 


IDENT 

* 

USERID 

LOWLOAD 

OPTION 

LIBRARY 

SELECT 

EXECUTE 

LIMITS 

PRMFL 

PRMFL 

DATA 


SPEC  DAYS=10  STAT=6  STRT=1 
3  6  24  34  41  53  * 


WP1355.MSMET  RUN  7 

****GRAPH  POST  PROCESSOR  USING  RUN  5  DATA  **** 

LCOM.II$XXXXXX 

FORTRAN, NOMAP 
SL 

LCOM.II/V3.0/GRPHCSTR 

15,I5K,-3K,5K 

SL,R,S,CACI/SIM2LIB 

17,R,S,CACI/SIMERR 

05 

5  STRT=I  STOP=60  DBUG=4 


PRMFL 

ENDJOB 


01,R,S,LCOM.II/V3.0/GRPH.OUT 


IDENT 

* 

USERID 

LIMITS 

LOWLOAD 

OPTION 

LIBRARY 

SELECT 

EXECUTE 

LIMITS 

PRMFL 

PRMFL 

DATA 

SPEC  DBUG=3 
PRMFL 
ENDJOB 


WP1355,MSMET  RUN  9 

****DI5PLAY  POST  PROCESSOR  USING  RUN  5  DATA  **** 

LCOM.II$XXXXXX 

10,,,6K 

FORTRAN, NOMAP 
SL 

LCOM.il/V3. 0/DSPLCSTR 
15,12K„5K 

SL,R,S,CACI/SIM2LIB 

17,R.5,CACI/SIMERR 

05 

01,R,S,LCOM.II/V3.0/DSPL.OUT 


SPEC 

$ 

$ 


IDENT 

* 

USERID 

LOWLOAD 

OPTION 

LIBRARY 

SELECT 

EXECUTE 

LIMITS 

PRMFL 

PRMFL 

DATA 


WP1355,MSMET  RUN  10 

****MIS5ION  POST  PROCESSOR  USING  RUN  5  DATA**** 

LCOM.II$XXXXXX 

FORTRAN, NOMAP 
SL 

LCOM.II/V3.0/MSNCSTR 


LIMITS  15,20K„15K 

PRMFL  SL,R,S,CACI/SIM2LIB 

PRMFL  17,R,S,CACI/SIMERR 

DATA  05 

IN=9  STOP=60  LVLU10  LVL2=3  NERR=50  * 
TAPE  09,X9DD„XXXXX„RFS.DATA 

ENDJOB 


3 


Table  A-l  cont. 


$$  IDENT 
* 

USERID 
SELECT 
EXECUTE 
TAPE 
TAPE 
FILE 
FILE 
FILE 

LOWLOAD 
OPTION 
LIBRARY 
SELECT 
EXECUTE 
LIMITS 
PRMFL 
PRMFL 
DATA 
SPEC  IN=1  NUM-1 
10  * 

$  TAPE 

$  ENDJOB 


MSMET  RUN11 

****SUPPORT  EQUIPMENT  PP  USING  RUN  5  DATA**** 

LCOM.n$XXXXXX 

LCOM.il/V3. 0/SEQSORT 

SA,X1DD„XXXX„SEQ.DATA 

SZ,X2S„XXXXX„SEQ.OUT 

51, A1R,50R 

52, A2R,50R 

53, A3R,50R 

FORTRAN 

SL 

LCOM.II/V3.0/SEQCSTR 
5, 14K 

SL,R,S,CACI/SIM2LIB 

17,R,S,CACI/SIMERR 

05 


01,X2DD 


SYSTEM  TEST  RUN  INTERFACES  CONT'D  Run  »  as  shown  on  right 
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V.  Standard  Systems  Release  (CPC) 

Version  3.5E,  dated  12  October  1979,  is  the  systems  release  herein  described. 

A.  Systems  Release  Tape 

The  seven  track  tape  (nine  track,  if  necessary)  provided  for  the  LCOM  II  System  Release  contains 
all  the  necessary  program  and  data  files  for  system  implementation  and  initial  checkout  with 
sample  problem  #3.5.  In  the  write-up  and  listings  that  follow,  all  file  and  tape  names  are  recom¬ 
mended  names  for  consistency  of  descriptions  permanent  file  sizes  given  are  appropriate  sizes 
required  for  the  initial  checkout  runs.  Unless  you  have  several  thousand  PRU's  of  permanent  file 
space  available,  you  should  put  the  large  test  files  on  magnetic  tape. 

B.  Release  Tape  File  Descriptions 


Permanent 

Permanent 

File  # 

Description 

File  Name 

File  Size 

1 

Input  Module  Object 

INPTOBJ 

509  PRU's 

2 

Main  Module  Object 

MAINOBJ 

1001 

3 

Pack-Unpack  Object 

PACKOBJ 

3 

4 

Decoder  Object 

DCDROB3 

124 

5 

Parts  Post  Processor  Object 

PRTSOBJ 

40 

6 

Graph  Post  Processor  Object 

GRPHOB1 

53 

7 

Matrix  Post  Processor  Object 

MTRXOBJ 

251 

8 

Display  Post  Processor  Object 

DPLYOBJ 

36 

9 

Mission  Post  Processor  Object 

MS NOB J 

187 

10 

Support  Equipment  Post  Processor  Object 

SEQOBJ 

59 

11 

Input  Module  Data  (Sample  Problem  #3.5) 

SP3DATA 

39 

12 

Main  Module  Change  Card  Data  (Unconstrained) 

CHNGUNC 

8 

13 

Main  Module  Change  Card  Data  (Constrained) 

CHNGCON 

8 

C.  Additional  Files  Needed  to  Make  the  Sample  Problem  #3.5  Full  Systems  Test 


Description 

File  Name 

Size 

60-Day  Exogenous  File  (produced  by  Input  Module) 

SP3EXOG 

242 

Initialization  File  (produced  by  Input  Module) 

SP3INIT 

57 

Unconstrained  Main  Module  Output 

SP3UNC 

10680 

Constrained  Main  Module  Output 

SP3CON 

10544 

Graph  Data  (produced  by  Decoder) 

SP3GRPH 

66 

Parts  Dictionary  (produced  by  Decoder) 

SP3PDIC 

1 

Parts  Data  (produced  by  Decoder) 

SP3PRTS 

928 

Matrix  Dictionary  (produced  by  Decoder) 

SP3MDIC 

1 

Matrix  Data  (produced  by  Decoder) 

SP3MTRX 

5848 

Realized  Flying  Schedule  Data  (produced  by  Decoder) 

SP3RFS 

536 

Support  Equipment  Data  (produced  by  Decoder) 

SP3SEQ 

400 

Display  Data  (produced  by  Decoder) 

SP3DPLY 

38 

D.  Run  Control  Cards 

1.  The  job  streams  necessary  to  copy  the  LCOM  II  system  release  tape  to  permanent 
files  and  conduct  test  runs  are  described  in  the  chart  below  and  are  included  in  Table  A-2. 
Figure  A-13  contains  charts  showing  the  interfaces  among  runs  3  to  11.  The  file  names  used  in 
these  charts  and  listings  relate  to  the  file  names  specified  in  paragraphs  B  and  C. 


Run  // 


Description 


2  SS  Ihtl  C°P-eS  !lCOM  Permanent  ^sc  files  to  the  Systems  Release  Tape. 

Job  that  copies  the  tape  files  to  permanent  disc  files.  ^ 

5  InPut  Module  run  of  sample  problem  //3.5. 

Main  Module  run  (Unconstrained)  using  data  produced  by  Run  3. 

Decoder  run  using  data  from  Run  4. 

6  Parts  Post  Processor  using  data  from  data  from  Run  5. 

'  Graph  Post  Processor  using  data  from  Run  5. 

*  Matrix  Post  Processor  using  data  from  Run  5. 

,  Display  Post  Processor  using  data  from  Run  5. 

! ,  Mission  Post  Processor  using  data  from  Run  5. 

I  Support  Equipment  Post  Processor  using  data  from  Run  3. 

fi rations  il'Th  °f.course>  You  must  substitute  your  own  job  names,  tape  VSNs,  owner  identi¬ 
fications,  and  other  changes  to  these  runs  to  satisfy  your  local  system  requirements  For  in 
stanoa,  the  CDC  system  at  ASD  at  WPAFB  requires  'an  owner  m  SThe Z!od  o'  L  ‘Td 

thS  jotfcard. require  a"  owner  ID  on  ,he  Permanent  file  control  cards  if  the^  apply  to  the  ID  on 

Description  of  Test  Runs  and  Results  (for  checkout  purposes) 

1.  Run  //I  -  System  copy  to  tape  -  performed  by  AFMSMET  only. 

2.  Run  //2  -  Copy  Systems  Release  Tape  on  to  disc  files  -  users  initial  run. 

3.  Run  //3  -  Input  Module. 

The.  rv,  e  //  warning  and  information  messages  will  be  found  throughout  the  listing 

The  message  //  and  quantity  found  are  as  follows  (///Qty);  41/1,  144/7  140/1  20/1  67/1  16/?* 

the  SPEC  card  option  INFO=3,  the  node  range  report  (MSG  17)  will  be  printed  in  full.*  ’ 


b.  Total  sorties  generated  by  Mission  Type  (report): 


MSNAME 

PREFLT 

RECON 

INTRD1 

CLSPT1 

CLSPT2 

INTRD2 

INTRD3 

FERRY1 

FERRY2 


NO.  MISSIONS 


NO.  SORTIES 


FLYING  HOURS 

0. 

480.000 
368.479 
1 30. 27 1 
362.256 
179.074 
60.000 
126.834 
251.902 


c.  Input  Data  Summary  (report): 


A-32 


Qty 


Description 


23 

96 

130 

163 

11 

9 

3 

6 

9 

13 

70 

9 

1 

2 

2 

9 

3 

10 

10 

2 


Resources 

Task  Names 

Node  Names 

Control  Table  Entries 

Failure  Clocks 

Mission  Entry  Points  (IETB) 

Resources  Entering  Network  (NACO) 

Total  //  of  Configurations  Defined  (All  A/C)  NCRS) 
Search  Patterns  (NSRPT) 

Next  Higher  Failures  (NNHF) 

Task  Resource  Requirements  (TRR) 

Unique  Groups  of  Clock  Decrements  (NOCL) 

Unique  Pieces  of  Internal  Equipment  (EQUIP) 
Internal  Equipment  Groups  (ILIST) 

Triggering  Events  (NTEVT.DV) 

Operations  Headings  on  Form  10 
Aircraft  Headings  on  Form  10 
Personnel  Headings  on  Form  10 
Part  Headings  on  Form  10 
AGE  Headings  on  Form  10 


d.  To  insure  full  preparation  of  an  initialization  file,  two  messages  must  follow  the 
printing  of  the  dictionaries.  These  messages  are  as  follows  and  may  be  separated  by  a  printout  of 
the  entire  initialization  file  data. 


.  MAIN  MODEL  INIT  IS  TO  BE  PRODUCED 
.  LEGITIMATE  END  MARKER  READ 
9.  Run  //4  -  Main  Module  Run  (Unconstrained): 

This  new  sample  problem  //3.5  does  not  provide  a  fully  unconstrained  run.  The  applicable  camera 
technicians  are  slightly  constrained  and  the  pre-sortie  time  line  for  internal  reconfigurations  may 
require  adjustment  to  permit  an  unconstrained  10096  flying  support.  It  is  expected  that  future 
versions  of  this  sample  problem  will  again  produce  truly  unconstrained  run  results. 

a.  Unconstrained  Run 


(1)  From  the  Level  II  day  10-60  Performance  Summary  Report,  the  following 
selected  statistics/total  values  are  given: 


» 

Statistic 

Value 

3 

Percent  accomplished 

99.60 

8 

Percent  accomplished 

98.81 

T4 

Number  of  attritions 

5.00 

T5 

Number  of  RAM  Repairs 

1.00 

23 

Avg  No.  of  Sorties/aircraft/day 

1.37 

24 

Flying  Hours 

1612.07 

33 

Number  of  Men  Demanded 

32455.00 

40 

Simulated  MH  Per  Flying  Hour 

11.81 

44 

No.  of  Reparable  Generations 

6612.00 

57 

Number  of  Units  Demanded 

6771.00 

75 

Number  of  Units  Demanded 

1094.00 

10.  Run  //1 0  -  Mission  Post  Processor  (Unconstrained):  See  Figure  A -21  for  the  final 
level  3  Mission  Statistics  Summary  Report. 

11.  Run  //  11  -  Support  Equipment  Post  Processor  (Unconstrained):  See  Figure  A-22  for 
the  Model  on-equipment  demands  for  resource  truck  and  Figtre  A-23  for  the  Actual  on-equip¬ 
ment  demands. 


F.  SIMSCRIPT  n  Systems  Release 


All  installations  using  CDC  LCOM  II  are  responsible  for  obtaining  their  own  SIMSCRIPT  II. 5 
compiler  maintenance.  Latent  errors  found  in  the  final  release  of  the  Navy  Compiler  make  a 
subsequent  release  under  a  GSA  maintenance  contract  a  preferred  compiler  for  use  with  the 
LCOM  II  system.  As  such,  AFMSMET  will  ensire  complete  LCOM  II  operation  on  the  latest 
release  of  the  CDC  SIMSCRIPT  II.5  compiler.  AFMSMET  can  provide  absolute  files  to  those 
government  installations  where  there  is  no  SIMSCRIPT  II. 5  compiler.  However,  any  computer 
system  software  differences  that  prevent  the  SIMSCRIPT  II  execution  library  from  functioning 
will  preclude  AFMSMET's  support  to  such  installations. 


G.  System  Improvements  -  Included  in  IV.H. 


H.  Error  Corrections  (from  previous  versions)  -  Included  in  above 


I.  Known  Errors  -  Included  in  IV.  J 


TABLE  A-2  CDC  RELEASE  3. 5 RUNS  -  3  CL 


Run  #2  3ob  Stream  to  Copy  Tape  Files  to  Permanent  Disc  Files 


XXXXX,MT1, 10200. 

REQUEST, TAPE, MT,HY,VSN=XXXXX, NORING. 
REQUEST,  INPTOB3,*PF. 

COP  YBF, TAPE, IOPTOBJ. 

CATALOG,  INPTOB3,RP=999,ID=X. 

REQUEST, MAINOB3,*PF. 

COPYBF, TAP  E,MAINOB3. 

CATALOG, MAINOB3,RP=999,ID=X. 

REQUEST, PACK, *PF. 

COPYBF, TAPE, PACK. 

CATALOG, PACK, RP=999,ID=X. 

REQUEST,  DCDROB3,*PF. 

COP  YFB, TAPE, DCDROB3. 

CATALOG  ,DCDROB3,RP=999,ID=X. 

REQUEST, PRTSOB3,*PF. 
COPYFB,TAPE,PRTSOB3. 

CATALOG, PRTSOB3,RP=999,ID=X. 
REQUESTER  PHOB  3,*PF. 

COP  YFB, TAPE, GRPHOBJ. 

CATALOG, GRPHOB3,RP=999,ID=X. 

REQUEST,  MTRXOB3,*PF. 

COPYBF, TAPE, MTRXOB3. 

CATALOG, MTRXOB3,RP=999,ID=X. 

REQUEST,  DPLYOB3,*PF. 

COPYBF, TAPE, DPLYOB3. 

CATALOG  ,DPLYOB3,RP=999,ID=X. 
REQUEST,MSNOB3,*PF. 

COPYBF, TAPE, MSNOB3. 

CATALOG, MSNOB3,RP=999,ID=X. 

REQUEST, SEQOB3,*PF. 

COPYBF, TAPE, SEQOB3. 

CATALOG, SEQOB3,RP=999,ID=X. 

REQUEST, SP3DATA,*PF. 

COPYBF, TAPE, SP3DATA. 

CATALOG, SP3DATA,RP=999,ID=X. 

REQUEST,  CHNGUNC,*PF. 

COPYBF, TAPE, CHNGUNC. 

CATALOG, CHNGUNC,RP=999,ID=X. 

REQUEST, CHNGCON,*PF. 

COPYBF, TAPE, CHNGCON. 

CATALOG, CHNGCON,RP=999,ID=X. 

6/7 /8/9 


A- 36 


TABLE  A-2  CONT'D 

Run  //6  Parts  Post  Processor  Using  Data  from  Run  #5 

XXXXX,CM60000,T40,I050. 

ATTACH, PBCD,SP3PRTS,ID=X. 

REQUEST, SIMU  1,*PF. 

FILE,PBCD,BT=C,RT+Z,FL=80. 

FILE,SIMU  1,BT=C,RT=Z,FL=80. 

SORTMRG. 

REWIND, SIMU  1. 

ATTACH, LGO, PRTSOBJ,ID=X. 

ATTACH, SIM2LIB,ID=CACI,SN=SYSTEM. 

ATTACH, SIMU3,SP3PDIC,ID=X. 

LGO. 

7/8/9. 

SORT 

FILE,INPUT=PBCD,OUTPUT=SIMU  1 

FIELD, PART(1, 6, DISPLAY), TIME(7, 10, DISPLAY) 

KEY,PART(A,COBOL6),TIME(A,COBOL6) 

END 

7/8/9 

SPEC  IN=1  DICT=3  DAYS=60 
6/7/8/9 


Run  //7  Graph  Post  Processor  Using  Data  from  Run  //5 

XXXXX,CM60000. 

ATTACH,  LGO,  GRPHOBJl,ID=X. 

ATTACH, SIM2LIB,ID=CACI,SN=SYSTEM. 

ATTACH, SIMU  1,SP3GRPH,ID=X. 

LGO. 

7/8/9 

SPEC  DAYS=10  STAT=6  STRT=0  STOP=60 
3  6  24  34  41  53  * 

6/7 /8/9 


O 


A- 39 


TABLE  A-2  CONT'D 


Run  OS  Manpower  Matrix  Post  Processor  Using  Data  from  Run  05 

XXXXX,CM70000,T300, 10300. 

REQUEST, SIMU9,SP3MTRX,ID=X. 

REQUEST, SIMU  I, *PF. 

FILE,SIMU9,BT=C,RT=Z,FL=80. 

FILE, SIMU  1,BT=C,RT=Z,FL=80. 

SORTMRG. 

RE  WIND, SIMU  1. 

ATTACH, SIM2LIB,ID=CACI,SN=SYSTEM. 

ATTACH, LGO,MTRXOB3,ID=X. 

ATTACH, SIMU3,SP3MDIC,ID=X. 

LGO. 

7/8/9 

SORT 

FILE,INPUT=SIMU9,OUTPUT=SIMU  1 

FIELD,  RCD(1,1DISPLAY),CWC(2, 4,  DISPLAY), TIME(6, 10,  DISPLAY) 
KEY,CWC(A,COBOL6),RCD(A,COBOL6),TIME(A,COBOL6) 

END 

7/8/9 

SPECIN=1  DICT=3  NUM=9  STOP=60  NBLK=2  BLK1=5  BLK2=2  STRT=10 

CREWCH 125300081 6 

CREWCH225300081 6 

OMPERS1 25300081 6 

OMPERS2253')0081 6 

FLTENG1253000816 

FLTENG225300081 6 

HYDTEC1253000816 

HYDTEC225300081 6 

HYDSPL1 25300081 6 

HYDSPL225300081 6 

COMTEC 125300081 6 

COMTEC225300081 6 

COMSPL1 25300081 6 

COMSPL2253G0081 6 

MUNSPL1 253051 321 

MUNSPL2253051 422 

C  AMTEC 1 253051 422 

C  AMTEC2253051 422 

6/7 /8/9 


TABLE  A-2  CONT'D 


* 

Run  //9  Display  Post  Processor  Using  Data  from  Run  //5 

XXXXX,CM44000. 

ATTACH, LGO,DPLYOBJ,ID=X. 

ATTACH, SIM2LIB,1D=CACI,SN=SYSTEM. 

ATTACH, SIMU  lkSP3DPLY,ID=X. 

LGO. 

7/8/9 

SPEC  1N=1 
6/7 /8/9 


Run  //1 0  Mission  Post  Processor  Using  Data  from  Run  //5 

XXXXX.CM55000. 

ATTACH, LGO  ,MSNOBJ,ID=X. 

ATTACH, SIM2LIB,ID=CACI,SN=SYSTEM. 

ATTACH, SIMU9,SP3RFS,ID=X. 

LGO. 

7/8/9 

SPEC  IN=9  STRT=10  STOP=60  LVL1=10  LVL2=3 
6/7  /8/9 


Run  //1 1  Support  Equipment  Post  Processor  Using  Data  from  Run  //5 

XXXXX,CM70000,T1 00,10200. 

ATTACH, SP3SEQ,1D=X. 

FILE, SIMU  1,BT=C,RT=Z,FL=80. 

FILE,SP3SEQ,BT=C,RT=Z,FL=80. 

SORT  MR  G. 

REWIND, SIMU  1. 

ATTACH, LGO, SEQOB3. 

LGO. 

7/8/9 
SORT 

FILE,INPUT=SP3SEQ,OUTPUT=SIMUl 
FIELD, ID(4, 6, DISPLAY),RC(1, 2, DISPLAY), TI(20, 1 1, DISPLAY) 
KEY,ID(A,COBOL6),RC(A,COBOL6),TI(A,COBOL6) 

SEQUENCE, COBOL6 
EQUATE, COBOL6(  ,0) 

END 
7/8/9 

SPEC  IN=I  NUM=i  DBUG=1  STRT=0  STOP=60  * 

10 
7/8/9 
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VI.  STANDARD  SYSTEM  RELEASE  (IBM) 

Version  3.5,  dated  12  October  1979  is  the  systems  release  herein  described. 


A.  System  Release  Tape 

The  nine  track  tape  produced  for  the  LCOM  II  Systems  Release  contains  ail  the  necessary  pro¬ 
gram  and  data  files  for  system  implementation  and  initial  check  out  with  sample  Problem  //3.5. 
In  the  write-up  and  listings  that  follow,  all  names  shown  for  data  sets  on  disk  or  tape  are  recom¬ 
mended  names  for  consistency  of  description.  Data  Set  sizes  given  are  the  approximate  sizes 
required  for  the  initial  unloading  of  the  tape  files. 


B.  Release  Tape  File  Description 


Data  Set 

Data  Set 

File  // 

Description 

Name 

Size  (Tracks) 

1 

Input  Module  BIN  LKED 

INPTSTND 

21 

2 

Simulation  Module  BIN  LKED 

MAINSTND 

35 

3 

Decoder  P.P.  BIN  LKED 

DCDRSTND 

8 

4 

Manpower  Matrix  P.P.  BIN  LKED 

MTRXSTND 

12 

5 

Display  P.P.  BIN  LKED 

DPLYSTND 

5 

6 

Parts  P.P.  BIN  LKED 

PRTSSTND 

5 

7 

Graph  P.P.  BIN  LKED 

GRPHSTND 

6 

8 

Mission  P.P.  BIN  LKED 

MISNSTND 

10 

9 

Support  Equip  P.P.  BIN  LKED 

SEPPSTND 

5 

10 

Sample  Problem  Forms 

SAMPPROB 

1 

11 

Change  Card  File  (Unconstrained) 

CHNGUNC 

1 

12 

Change  Card  File  (Constrained) 

CHNGCON 

1 

C.  Additional  Disk/Tape  Files  Needed  to  Make  Full  System  Test. 


Data  Set  Name 

Description 

Type  Data 

EXOG60D 

60  Day  Exogenous  File 

BCD 

INITSP 

Sample  Problem  Initialization  File 

BIN 

GRPHOUT 

Graph  Data  Produced  by  SIMR UN/DECODER 

BIN 

PRTSDICT 

Parts  Dictionary  Produced  by  SIMRUN/DECODER 

BIN 

MTRXDICT 

MTRX  Dictionary  Produced  by  SIMRUN/DECODER 

BIN 

DSPLOUT 

Display  Data  Produced  by  SIMRUN/DECODER 

BIN 

USIMOUT 

Integrated  SIMR  UN  Unconstrained  P.P.  output 

BIN 

CSIMOUT 

Integrated  SIMRUN  Constrained  P.P.  output 

BIN 

ISIMOUT 

Initialization  Data  for  SIMRUN 

BCD 

PRTSBCD 

Output  of  DECODER  forPARTS  SORT 

BCD 

PRTSOUT 

PRTS.BCD  File  Sorted 

BCD 

MTRXBCD 

Output  of  DECODER  for  MTRX  SORT 

BCD 

MTRXOUT 

MTRX.BCD  File  Sorted 

BCD 

RFSDATA 

Realized  Flying  Schedule  output  from  DECODER 

BCD 

SEQDATA 

Support  Equipment  Date  output  from  DECODER 

BCD 

SEPPBCD 

Output  of  DECODER  for  SEPP  SORT 

BCD 

D.  Run  Control  Cards 


1.  Job  control  language  (Control  Cards)  necessary  to  copy  the  LCOM  II  system  release  tape 
to  Disk  Data  Sets  and  conduct  test  runs  are  described  below  and  are  included  in  table  A-3. 
Figure  A-20  contains  charts  showing  the  interfaces  between  runs  3  thru  9.  Data  set  names  within 
these  listings  and  charts  make  reference  to  the  same  data  set  names  specified  in  para  B  and  C 
above.  The  data  set  name  of  all  the  LCOM  programs'  binary  link-edited  object  files  is 
XXXXXXX.LCOMCOMP. 


1  Utility  Program  to  copy  11  LCOM  II  System  Disk  Files  to  the  Systems  Release  Tape. 

2  Utility  Program  to  copy  1 1  tape  files  to  disk. 

3  Input  Module  Run  of  provided  Sample  Problem. 

4  Main  SIMRUN  (Unconstrained)  using  Data  from  Run  3. 

5  Decoder  Run  using  Data  from  Run  4. 

6  Parts  Post  processor  run  using  Data  from  Run  5. 

7  Graph  Post  Processor  Run  using  Data  from  Run  5. 

8  Manpower  Matrix  Post  Processor  Run  using  Data  from  Run  5. 

9  Display  Post  Processor  Run  using  Data  from  Run  5. 

10  Mission  Post  Processor  Run  using  Data  from  Run  5. 

1 1  Support  Equipment  Post  Processor  Run  using  Data  from  Run  5. 

2.  Note:  The  Input  Module  Run,  Run  //3,  is  processing  this  test  case's  Initialization  Process 
and  Sortie  Generation  Process  together.  However,  with  large  data  bases  these  processes  are 
normally  run  separate  using  appropriate  null  files.  Substitutions  to  satisfy  your  own  computer 
system's  requirements  may  also  be  required. 

E.  Description  of  Test  Run  Results  (For  checkout  purposes) 

1.  Run  #1  -  System  copy  to  tape  -  Performed  by  AFMSMET  only. 

2.  Run  #2  -  UTILITY  (Tape  to  Disk)  -  Users  initial  run. 

3.  Run  //3  -  Input  Module. 

a.  Legal  warning  and  information  messages  will  be  found  throughout  the  listing.  The 
message  //  and  quantity  found  are  as  follows  (///Qty);  41/1,  144/7,  140/1,  20/1,  67/1,  16/1,  17/1, 
24/1  (NONE),  36/1  (NONE),  11/1  (NONE),  96/1  (7  entries),  97/1  (NONE),  79/1  (NONE),  80/1 
(NONE),  4/1  (1  entry),  146/1  (NONE),  147/1  (NONE),  117/1  (NONE),  31/1  (1  entry),  and  53/1. 
Also,  with  SPEC  card  option  INFO=3,  the  node  range  report  (MSG  17)  will  be  printed  in  full. 

b.  Total  sorties  generated,  by  mission  type  (report): 

MS  NAM  NO  MSN  NO  SORT  FLY  HRS 


PREFLT 

RECON 

INTRD1 

CLSPT1 

CLSPT2 

INTRD2 

INTRD3 

FERRY  1 

FERRY2 


c.  Input  Data  Summary  (report): 


23 

96 

130 

163 

11 

9 

3 

6 

9 

13 

70 

Q 

1 

2 

2 

9 

3 

10 

10 

2 


Resources 

Task  Names 

Node  Names 

Control  Table  Entries 

Failure  Clocks 

Mission  Entry  Points  (IETB) 

Resources  Entering  Network  (NACO) 

Total  //  of  Configurations  Defined  (All  A/C)  (NCRS) 
Search  Patterns  (NSRPT) 

Next  Higher  Failures  (NNHF) 

Task  Resource  Requirements  (TRR) 

Unique  Groups  of  Clock  Decrements  (NOCL) 

Unique  Pieces  of  Internal  Equipment  (EQUIP) 
Internal  Equipment  Groups  (ILIST) 

Triggering  Events  (NTEVT.DV) 

Operations  Headings  on  Form  10 
Aircraft  Headings  on  Form  10 
Personnel  Headings  on  Form  10 
Part  Headings  on  Form  10 
AGE  Headings  on  Form  10 


d.  To  insure  full  preparation  of  an  initialization  file,  two  messages  must  follow  the 
printing  of  the  dictionaries.  These  messages  are  as  follows  and  may  be  followed  by  a  printout  of 
the  entire  initialization  file  data  and  an  additional  message  "LEGITIMATE  END  MARKER 
READ". 


.  MAIN  MODEL  INIT  FILE  IS  TO  BE  PRODUCFD. 

.  LEGITIMATE  END  MARKER  WRITTEN 

4.  Run  //4  -  Main  Module  Run  (Unconstrained): 

This  new  sample  Problem  //3  does  not  provide  a  fully  unconstrained  run.  The  applicable  camera 
technicians  are  slightly  constrained  and  the  pre-sortie  time  line  for  internal  reconfigurations  may 
require  adjustment  to  permit  an  unconstrained  100%  flying  support.  It  is  expected  that  future 
versions  of  this  sample  problem  will  again  produce  truly  unconstrained  run  results. 

a.  Uncortstrained  Run 

(1)  From  the  Level  II  day  10-60  Performance  Summary  Report,  the  following 
selected  statistics/ total  values  are  given: 


* 

Statistics 

Value 

3 

Percent  accomplished 

ioo.oo 

8 

Percent  accomplished 

99.78 

T4 

No.  of  Attritions 

2.00 

T5 

No.  of  RAM  Repairs 

5.0 

23 

Avg  No.  of  Sorties/  A/C  / Day 

1.32 

24 

Flying  Hours 

1602.60 

33 

No.  of  men  demanded 

32086.00 

40 

Simulated  MH  Fer  Flying  Hr 

11.72 

44 

No.  of  reparables  generated 

6558.00 

57 

No.  of  units  demanded 

6755.00 

75 

No.  of  units  demanded 

1070.00 

A-S9 


(2)  From  the  end  of  run  Stop  (or  Memory  Saved)  Report  at  time  1 00.01 ;  total  jobs 
started  =  57146,  jobs  completed  =  57146,  and  jobs  preempted  =  0. 

b.  Constrained  Run 

(1)  From  the  Level  11  day  10-60  Performance  Summary  Report,  the  following 
selected  statistics/total  values  are  given: 


n 

Statistics 

Value 

3 

Percent  accomplished 

95.2 

8 

Percent  accomplished 

93.48 

T4 

No.  of  Attrition 

2.00 

T5 

No.  of  RAM  repairs 

3.00 

23 

Avg  No.  of  Sorties/  A/C  /Day 

1.22 

24 

Flying  Hours 

1506.13 

33 

No.  of  men  demanded 

30935.00 

40 

Simulated  MH  Per  Flying  Hour 

12.10 

44 

No.  of  reparables  generated 

6468.00 

57 

No.  of  units  demanded 

6519.00 

62 

No.  of  cannibal izations 

8.00 

75 

No.  of  units  demanded 

1037.00 

(2)  From  the  end  of  run  Stop  (or  Memory  Saved)  Report  at  time  100.01;  total  jobs 
started  =  55240,  jobs  completed  =  55192,  and  jobs  preempted  =  48. 

5.  Run  //5  Decoder  Run  (Unconstrained):  A  two  page  report  is  printed  as  shown  in  Figure 
A-20.  The  number  of  records  written  to  the  GRAPH  file  printed  because  the  DECODER  P.P. 
was  executed  only  for  the  purpose  of  executing  the  GRAPH  P.P.  later.  The  number  of  records 
written  to  the  other  post  processors  is  as  follows: 


428 

10 

11800 

1 

92767 

5741 

1245 

0 


RECORDS  WERE  WRITTEN  TO  THE  DISPLAY  FILE. 


RECORDS  WERE  WRITTEN 
RECORDS  WERE  WRITTEN 
RECORDS  WERE  WRITTEN 
RECORDS  WERE  WRITTEN 
RECORDS  WERE  WRITTEN 
RECORDS  WERE  WRITTEN 
RECORDS  WERE  WRITTEN 


PARTS  BINARY 
PARTS  BCD 
MATRIX  BINARY 
MATRIX  BCD 
RFS 

SUPPORT  EQUIPMENT 
TASK  POST  PROCESSOR 


6.  Run  //6  Parts  Sort  and  Parts  Post  Processor  (Unconstrained) 


a.  Parts  Sort  Records  Input  =  11800,  Records  output  =  11800. 


b.  See  Figure  A-22  for  run  results. 

7.  Run  //7  GRAPH  POST  Processor.  (Unconstrained) 

a.  See  Figure  A-23  for  Histogram  of  post  sortie  A/'C  turnaround  times. 

b.  See  Figure  A-24  for  graph  of  Stat  22  (Avg  AC  Post-Sortie  Time  (Hrs). 

8.  Run  //8  Marix  Sort  and  Matrix  Post  Processor  (Unconstrained). 

a.  MTRX  SORT  -  Records  Input  =  92767.'  Records  Output  =  92767. 


-  _ _  _  _ _ 
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b.  See  Figure  A-25  for  one  set  of  matrices  (two  parts)  printed  in  the  run. 

9.  Run  // 9  Display  Post  Processor  (Uncon).  See  Figure  A-26  for  the  first  full  display  of 
each  aircraft  (Day  0  and  Day  16). 

10.  Run  //10  Mission  Post  Processor  (Uncon).  See  Figure  A-27  for  the  final  Level  2  Mission 
Success  Statistics  Summary  Report. 

11.  Run  //1 1  Support  Equipment  Post  Processor  (Uncon.).  See  Figure  A-28  for  the  model 
and  actual  on-equipment  demands  for  the  resource  called  truck  in  the  sample  problem. 

F.  SIMSCR1PT  II  Systems  Release 

All  installations  using  LCOM  II  are  responsible  for  obtaining  their  own  SIMSCRIPT  n.5  compiler 
maintenance.  AFMSMET  has  taken  extreme  care  in  attempting  to  provide  an  LCOM  II  model 
that  would  run  on  the  Final  Air  Force  release  //12.  However,  latent  errors  found  in  release  //1 2 
make  a  subsequent  release  under  a  GSA  maintenance  contract  a  preferable  compiler  for  use  with 
the  LCOM  II  system.  AFMSMET  can  provide  Binary  Link-edited  object  programs  to  those  Air 
Force  installations  where  there  is  no  compiler  maintenance  contract.  However,  the  user  is 
responsible  for  ensuring  that  the  software  at  his  computer  installation  is  compatible  with  the 
standard  software  release  in  use  at  Wright-Patterson  Air  Force  Base,  Ohio.  Any  computer 
system  software  differences  that  prevent  the  SIMSCRIPT  II  execution  library  from  functioning 
will  preclude  AFMSMET's  support  to  such  installations. 

G.  System  Improvements  -  Included  in  IV.H. 


H.  Known  Errors  -  Included  in  IV.3. 


Table  A-3  IBM  Release  3.5  Runs  -  JCL 


//RUN2  JOB  (XXXX, XXX, ,2) , 'REISS' ,MSGLEVEL=1, 

//  REGION  =100K,TIME=2,CLASS=C 
//*  UTILITY  JCL  TO  COPY  11  TAPE  FILES  TO  DISK 
//LOAD  EXEC  PGM=IEBCOPY 
//SYSPRINT  DD  SYSOUT=A 

//FROM  DD  DSN=LCOMREL , UNIT=TAPE , LABEL= ( , NL) , 

VOL=SER=XXXXXX , DISP=OLD 

//TO  DD  DSN=LCOMPGMS ,UNIT=3330, VOL=SER=XXXXXX, 

//  DISP= (NEW , KEEP) , DCB= (DEN=X) , SPACE= (CYL, (5,2), RLSE) 

//SYSUT3  DD  DSN=TEMP,UNIT=3330,DISP= (NEW, DELETE), 

//  VOL=SER=XXXXXX , SPACE= (TRK , (2)) 

//SYS IN  DD  * 

COPY  OUTDD=TO, INDD=FR0M 


//RUN3  JOB  (XXXX, XXX,, 3),' REISS ' ,MSGLEVEL=1 , 

//  REGION=250K,TIME=1 ,CLASS=C 

//*  INPUT  MODEL  RUN  OF  PROVIDED  SAMPLE  PROBLEM 

// INP  EXEC  PGM=INPTSTND 

//STEPLIB  DD  DSN=XXXXXXX . LCOMCOMP , DISP=SHR 
//SIMU17  DD  DSN=A750265 . CACI . SIMERR8 , DISP=SHR 
/ /SIMU06  DD  SYSOUT=A,DCB= (RECFM=FBA,LRECL=133,BLKSIZE=1330) 
//SIMU05  DD  * 

SPEC  FORM=l  PRNT=6  INIT=7  INFO=3  EXOG=9 


//SIMU07  DD  DSN=INITSP,DISP= (NEW, CATLG, DELETE) , 

//  DCB= (BLKSIZE=800,RECFM=FB , LRECL=800) , UNIT=3330 , 

//  VOL=SER=XXXXXX,SPACE= (CYL, (5, 2), RLSE) 

//SIMU01  DD  DSN=SAMPPROB,DISP=OLD,UNIT=TAPE,VOL=SER=XXXXXX 
//  DCB= (RECFM=FB , LRECL=80 ,BLKSIZE=800) , LABEL= (1 ,NL) 

//SIMU09  DD  DSN=EXOG60D, DISP= (NEW, CATLG, DELETE) , 

//  UNIT=3330 , VOL=SER=XXXXXX, SPACE* (CYL, (5,2), RLSE) , 

//  DCB=(RECFM=FB , LRECL=800 , BLKSI ZE*800) 


Table  A-3  cont'd. 


/ /RUN4U  JOB  (XXXX,  XXX,,  6),' REISS \MSGLEVEL=1, 

//  REGION=450K,TIME=10,CLASS=Z 

//*  MAIN  SIMRUN  (UNCON)  USING  RUN 3  DATA 

//MAIN  EXEC  PGM=MAINSTND 

//STEPLIB  DD  DSN=XXXXXXX . LCOMCOMP , DISP=SHR 

//SIMU17  DD  DSN=A750265 . CACI . SIMERR8 , DISP=SHR 

/ /SIMU06  DD  SYSOUT=A 

/ /SIMU05  DD  * 

SPEC  CHNG=1  INIT=7  EXOG=9  POST=3  DATA=2 
/* 

/ /SIMU01  DD  DSN=CHNGUNC,DISP= (OLD, KEEP) 

//SIMU02  DD  DUMMY, DCB=(RECFM=FBA,LRECL=133,BLKSIZE=1330) 

/ /SIMU03  DD  DSN=USIMOUT, DISP= (NEW, KEEP) ,UNIT=TAPE,VOL=SER=XXXXXX, 
//  DCB=(RECFM=VB,LRECL=800,BLKSIZE=804) , LABEL=(1 ,NL) 

/ /SIMU07  DD  DSN=INITSP,  DISP'- (OLD,  KEEP) 

/ /SIMU09  DD  DSN=EXOCAOD,DISP=OLD,UNIT=TAPE,VOL=SER=XXXXXX, 

//  DCB= (RECFM=FB, LRECL=800 , BLKSIZE=800) , LABEL= (1 ,NL) 

/* 

// 

c 


**  EXCHANGE  CARDS  TO  MAKE  ABOVE  RUN  CONSTRAINED  ** 

//RUN4C  JOB  (XXXX, XXX,, 6), 'REISS', MSGLEVEL=1, 

//  REGI0N=450K,TIME=20,CLASS=Z 

//SIMU01  DD  DSN=CHNGCON,DISP= (OLD, KEEP) 

/ /SIMU03  DD  DSN=CS IMOUT , DISP= (NEW , KEEP) , UNIT=TAPE , 
//  VOL=SER=XXXXXX 


O 
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Table  A- 3  cont'd. 


//RUN5  JOB  (XXXX, XXX,, 3), 'REISS', MSGLEVEL=1, 

//  REGION=100K,TIME=5,CLASS=Z 

//*  DECODER  RUN  USING  RUN  4  DATA 

//DCDR  EXEC  PRM=DCDRSTND 

//STEPLIB  DD  DSN=XXXXXXX. LCOMCOMP,DISP=SHR 

//SIMU17  DD  DSN=A750265 . CACI . SIMERR8 , DISP=SHR 

//SIMU06  DD  SYSOUT=A,DCB= (RECFM=FBA, LRECL=133 , BLKSIZE=1330) 

//SIMU0S  DD  * 

SPEC  GRPD=9  PRTS=10  PBCD=14  MTRX=13  DPLY=12  SEQ=8  IN=1 
RFS=11  MBCD=15  DBUG=0 


/* 

//SIMU01 

DD 

DISP= (OLD , KEEP) , DSN=USIMOUT , UNIT=TAPE , 

// 

LABE1.=  (1,NL)  ,VOL=SER=XXXXXX, 

// 

DCB=(RECFM=VB, LRECL=800,BLKSIZE=804) 

/ /SIMU08 

DD 

DSN=SEQDATA,DISP= (NEW, KEEP) ,UNIT=TAPE, 

II 

LABEL= ( 1 , NL) , VOL=SER=XXXXXX , 

II 

DCB= (RECFM=FB , LRECL=56 , BLKSI ZE=560) 

//SIMU09 

DD 

DSN=GRPHOUT , UNIT=TAPE , DISP= (NEW , KEEP) , 

// 

LABEL=(1,NL) , VOL=SER=XXXXXX, 

// 

DCB= (RECFM=VB , LRECL=800 , BLKSIZE=804) 

/ /SIMU10 

DD 

DSN=PRTSDICT,DISP= (NEW, CATLG, DELETE) ,UNIT=3330, 

II 

VOL=SER=XXXXXX , SPACE= (TRK , (2,1) ,RLSE) , 

II 

DCB= (RECFM=VB, LRECL=800, BLKSIZE=804) 

//SIMU11 

DD 

DSN=RFSDATA,UNIT=TAPE , DISP= (NEW, KEEP) , 

// 

LABEL=(1,NL) ,VOL=SER=XXXXXX, 

// 

DCB= (RECFM=VB, LRECL=64, BLKSIZE=964) 

//SIMU12 

DD 

DSN=DPLYOUT, DISP= (NEW, CATLG , DELETE) , UNIT=3330 , 

// 

VOL=SER=XXXXXX , SPACE= (TRK , (2,1) ,RLSE) , 

// 

DCB= (RECFM=VB , LRECL=800 , BLKSIZE=804) 

//SIMU13 

DD 

DSN=MTRXD I CT , DI SP= (NEW .CATLG , DELETE) ,UNIT=3330 , 

// 

VOL=SER=XXXXXX,SPACE= (TRK, (2,1) ,RLSE) , 

// 

DCB= (RECFM=VB , LRECL=800 , BLKSI ZE=804) 

//SIMU14 

DD 

DSN=PRTSBCD,DISP= (NEW, KEEP) ,UNIT=TAPE, 

// 

LABEL=(1,NL) ,VOL=SER=XXXXXX, 

// 

DCB= (RECFM=FB , LRECL=48 , BLKSIZE=960) 

/ /SIMU15 

DD 

DSN=MTRXBCD , DISP= (NEW, KEEP) ,UNIT=TAPE , 

// 

LABEL=(1,NL) ,VOL=SER=XXXXXX, 

// 

/* 

DCB=  (RECFM=FB ,  LRECL=32 ,  BLKSUE=800) 

/ 

II 
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Table  A- 3  cont'd 


//RUN6  JOB  (XXXX, XXX,, 1), 'REISS’, MSGLEVEL=1, 

//  REGI0N=260K,TIME=2,CLASS=C 

//*  PARTS  POST  PROCESSOR  USING  RUN  5  DATA 

//SORT  EXEC  PGM=SORT, PARM= 1 MSG=AP ’ 

//SYSOUT  DD  SYSOUT=A 

//SORTLIB  DD  DSN=SYS1 . SORTLIB,DISP=SHR 
//SORTWK01  DD  UNIT=SYSDA,SPACE= (TRK, (100) , ,CONTIG) 
//SORTWK02  DD  UNIT=SYSDA, SPACE= (TRK, (100) , .CONTIG) 

/ /SORTWK03  DD  UNIT=SYSDA,SPACE=(TRK, (100) , .CONTIG) 
//SORTWK04  DD  UNIT=SYSDA,SPACE=(TRK, (100) , .CONTIG) 
//SORTIN  DD  DSN=PRTSBCD,DISP= (OLD, DELETE) ,UNIT=TAPE 
//  LABEL=(1,NL) , VOL=SER=XXXXXX, 

//  DCB= (RECFM=FB,LRECL=48 , BLKSIZE=960) 

//SORTOUT  DD  DSN=PRTSOUT,DISP=(,PASS) ,UNIT=SYSDA, 

//  SPACE= (TRK , (50 , 20) , RLSE) , 

//  DCB= (RECFM=FB , LRECL=48 , BLKSI ZE=960) 

//SYSIN  DD  * 

COL 


SORT  FIELDS=(1 , 6, CH, A, 7, 10,FL,A) ,SIZE=E24000 


/ /PRTS  EXEC  PGM=PRTSSTND 

//STEPLIB  DD  DSN=XXXXXXX . LCOMCOMP , D ISP=SHR 

//SIMU17  DI  DSN=A750265 . CACI . SIMERR8 , DISP=SHR 

//SIMU06  DD  SYSOUT=A,DCB=(RECFM=FBA, LRECL=133,BLKSIZE=1330) 

//SIMU05  DD  * 

SPEC  IN=14  DICT=10  DAYS=60 

//SIMU10  DD  DSN=PRTSDICT, DISP= (OLD , DELETE) 

/ /SIMU14  DD  DSN=PRTSOUT,DISP= (OLD, DELETE) 


/ /RUN7  JOB  (XXXX, XXX,, 2), ’REISS’, MSGLEVEL=1, 

//  REGION=100K, TIME=2 ,CLASS=C 

//*  GRAPH  POST  PROCESSOR  USING  RUN  5  DATA 

//GRPH  EXEC  PGM=GRPHS1ND 

//STEPLIB  DD  DSN=XXXXXXX. LCOMCOMP, DISP=SHR 

//SIMU17  DD  DSN=A750265 .CACI .SIMERR8, DISP=SHR 

//SIMU06  DD  SYSOUT=A,DCB=(RECFM=FBA,LRECL=133,BLKSIZE=1330) 

//SIMU09  DD  DSN=GRPHOUT,UNIT=TAPE,DISP= (OLD, DELETE) , 

//  LABEL*(l,NL),VOL=SER=XXXXXX 

//SIMU0S  DD  * 

SPEC  DAYS=10  STAT=6  STRT=1  ST0P=60  IN=9 
3  6  22  32  39  51  * 


Table  A-3  cont'd. 


//RUN8  JOB  (XXXX.XXX, ,5) , 'REISS' .MSGLEVEL--1, 

//  REGION=380K,TIME=5,CLASS=Z 

//*  MATRIX  POST  PROCESSOR  USING  RUN  5  DATA 

//SORT  EXEC  PGM=SORT , PARM= ' MSG=AP ' 

//SYSOUT  DD  SYSOUT=A 

//SORTLIB  DD  DSN=SYSl.SORTLIB,DISP=SHR 

//SORTWK01  DD  UNIT=SYSDA,SPACE=(TRK, (100) , .CONTIG) 

//SORTWK02  DD  UNIT=SYSDA,SPACE=(TRK, (100) , .CONTIG) 

//SORTWK03  DD  UNIT=SYSDA,SPACE=(TRK, (100) , .CONTIG) 

/ /SORTWK04  DD  UNIT=SYSDA,SPACE= (TRK, (100) , .CONTIG) 
//SORTWK05  DD  UNIT=SYSDA,SPACE= (TRK, (100) , .CONTIG) 
//SORTWK06  DD  UNIT=SYSDA,SPACE=(TRK, (100) , .CONTIG) 

//SORTIN  DD  DSN=MTRXBCD, DISP= (OLD, DELETE) ,UNIT=TAPE, 

//  VOL=SER=XXXXXXX,LABEL=(l,NL) , 

//  DCB= (LRECL=32,RECFM=FB,BLKSIZE=800) 

//SORTOUT  DD  DSN=MTRXOUT,DISP=(,PASS) ,UNIT=SYSDA,  .  f 
//  SPACE=(CYL, (5,2)) 

//  DCB=RECFM=FB , LRECL=32 , BLKSIZE=800) 

//SYS IN  DD  * 
col 

2 

SORT  FIELDS=(2,4,CH,A, 1, 1,CH,A,6, 10.CH.A) ,SIZE=E80000 
/* 

//MTRX  EXEC  PGM=MTRXSTND 

//STEPLIB  DD  DSN=XXXXXXX. LCOMCOMP,DISP=SHR 
//SIMU17  DD  DSN=A750265 .CACI .SIMERR8, DISP=SHR 
/ /SIMU06  DD  SYSOUT=A, DCB= (RECFM=FBA, LRECL=133, BLKSIZE=1330) 
//SIMU05  DD  * 

SPEC  IN=2  DICT=13  NUM=9  STRT=0  STOP=60  NBLK=2  BLK1=5 
BLK2=2  * 

CREWCH1253000816 
CREWCH2253000816 
0MPERS1253000816 
0MPERS2253000816 
FLTENG1253000816 
FLTENG2253000816 
HYDTEC1253000816 
HYDTEC2253000816 
HYDSPL 1253000816 
HY0SPL2253000816 
COMTEC 1253000816 
C0MTEC2253000816 
COMSPL 1253000816 
C0MSPL2253000816 
MUNSPL1253051321 
MUNSPL2253051422 
CAMTEC 1253051422 
CAMTEC2253051422 

/* 

/ /SIMU02  DD  DSN=MTRXOUT,DISP= (OLD, DELETE) 

/ /SIMU13  DD  DSN=MTRXDICT , DISP= (OLD , KEEP) 

/* 

// 
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Table  A-3  cont'd. 

//RUN9  JOB  (XXXX, XXX,, 5), 'REISS', MSGLEVEL=1, 

1 1  REGION=75K,TIME=l ,CLASS=C 

//*  DISPLAY  POST  PROCESSOR  USING  RUN  5  DATA 

//DPLY  EXEC  PGM=DPLYSTND 

//STEPLIB  DD  DSN=XXXXXXX . LCOMCOMP , DISP=SHR 

//SIMU17  DD  DSN=A750265 .CACI .SIMERR8, DISP=SHR 

//SIMU06  DD  SYSOUT=A, DCB=(RECFM=FBA, LRECL= 133, BLKSIZE= 1330) 

//SIMU12  DD  DSN=DPLYOUT,DISP= (OLD, DELETE) 

DD  * 

DEBUG=3 


//STEPLIB 
//SIMU17 
//SIMU06 
/ /SIMU12 
//SIMU05 
SPEC  IN=12 
/* 

// 


/ /RUN10  JOB  (XXXX, XXX,, 5),' REISS ',MSGLEVEL=1, 

//  REGION=100K,TIME=2,CLASS=C 

//*  MISSION  POST  PROCESSOR  USING  RUN  5  DATA 

//MSN  EXEC  PGM=MISNSTND 

//STEPLIB  DD  DSN=XXXXXXX. LCOMCOMP, DISP=SHR 

/ /SIMU17  DD  DSN=A750265. CACI .SIMERR8,DISP=SHR 

/ /SIMU06  DD  SYSOUT=A,DCB=(RECFM=FBA,LRECL=133,BLKSIZE=1330) 

//SIMU11  DD  DSN=RFSDATA, DISP= (OLD, KEEP) ,UNIT=TAPE, 

//  LABEL=(1,NL) , VOL=SER=XXXXXXX, 

//  DCB= (RECFM=VB, LRECL=64 , BLKSIZE=964) 

//SIMU05  DD  * 

SPEC  IN=11  LVL1=10  LVL2=6  NERR=50  STOP=60  * 

/* 

// 


//RUN11  JOB  (XXXX, XXX,, 10) , 'REISS' ,MSGLEVEL=1, 

//  REGION=200K,TIME=5,CLASS=A 

//*  SUPPORT  EQUIPMENT  POST  PROCESSOR  USING  RUN  %  DATA 
//SORT  EXEC  P  GM=  SORT , P ARM= ' MSG = AP ' 

//SYSOUT  DD  SYSOUT=A 

//SORTLIB  DD  DSN=SYS1 ,SORTLIB,DISP=SHR 

//SORTWK01  DD  UNIT=SYSDA,SPACE=(TRK, (100) , ,CONTIG) 

/ /SORTWK02  DD  UNIT=SYSDA,SPACE= (TRK, (100) , .CONTIG) 

/ /SORTWK03  DD  UNIT=SYSDA,SPACE= (TRK, (100) , .CONTIG) 

//SORTWK04  DD  UNIT=SYSDA, SPACE= (TRK, (100) , .CONTIG) 

//SORTWK05  DD  UNIT=SYSDA,SPACE= (TRK, (100) , .CONTIG) 

/ /SORTWK06  DD  UNIT=SYSDA,SPACE= (TRK, (100) , .CONTIG) 

//SORTIN  DD  DSN=SEPPBCD,DISP= (OLD, KEEP) ,UNIT=TAPE, LABEL= (1 ,NL) , 
//  VOL=SER=XXXXXX,DCB=(RECFM=FB, LRECL=56, BLKSIZE=560) 

//SORTOUT  DD  DSN=SEPPOUT,DISP=(NEW,PASS) ,UNIT=SYSDA, 

//  SPACE=(TRK, (30,10)), DCB= (RECFM=FB , LRECL=56 , BLKSIZE=560) 

//SYSIN  DD  * 
col 
2 

SORT  FIELDS= (4,6,CH,A,1,2,CH,A,20,11,FL,A) ,SIZE=E10000 
/* 

//SEPP  EXEC  PGM=SEPPSTND 

//STEPLIB  DD  DSN=XXXXXXX. LCOMCOMP, DISP=SHR 

/ /SIMU17  DD  DSN=A750265 . CACI . SIMERR8 , DISP=SHR 

/ /SIMU06  DD  SYSOUT=A, DCB= (RECFM=FBA, LRECL=133, BLKSIZE=1330) 

/ /SIMU01  DD  DSN=SEPPOUT,DISP= (OLD, DELETE) 

//SIMU05  DD  * 

SPEC  IN=1  STOP=60  NUM=1  * 

10  * 

/* 

//  A-67 
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SYSTEM  TEST  RUN  INTERFACES  CONT'D  Run  ,  as  shown  on  right 


FREQUENCY  HISTOGRAM  OF  POST  SORTIE  A/C  TURNAROUND  TIMES  L6I5  OBSERVATIONS  AVERAGE  TIME  3.06  HOURS  ST ANOARO  DEVIATION 


FIGURE  A-27.  S.P.  3.5's  POST  SORTIE  TURNAROUND  HISTOGRAM  (IBM) 


jRAPH  OF  STAT  22  AVo.  AC  POST  SORTIE  TIMt'(SRSI 
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Appendix  9 


All  user  and  programmer  oriented  messages  described  in  this  appendix  have  the  same  message  numbers 
that  are  printed  on  the  input  module  runs,  for  ease  of  reference  to  these  desciiptions.  However,  there 
are  some  internal  programmer  messages  generally  used  for  implementation  checkouts  that  will  not  have 
message  numbers.  Users  will  see  these  messages  only  if  a  serious  data  or  prog- am  problem  has 
occurred,  in  which  case,  the  AFM5MET  programming  staff  should  be  contacted. 


INPUT  MODULE  DIAGNOSTICS 
(Type  W  =  Warning,  I  =  Informational,  F  =  Fatal,  D  =  Data) 
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INPUT  MODULE  DIAGNOSTICS 
(Type  W  =  Warning,  I  =  Informational,  F  =  Fatal,  D  =  Data) 
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INPUT  MODULE  DIAGNOSTICS  (Cont'd) 
(Type  W  =  Warning,  1  =  Informational,  F  =  Fatal,  D  =  Data) 
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(Type  W  =  Warning,  I  =  Informational,  F  =  Fatal,  D  =  Data) 
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INPUT  MODULE  DIAGNOSTICS  (Cont'd) 
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Appendix  C 


Main  Module  Diagnostic  Messages 


All  user  and  programmer  oriented  messages  described  in  this  appendix  have  the 
same  message  numbers  that  are  printed  on  the  Ma'n  Module  runs,  for  ease  of 
reference  to  these  descriptions.  Howeve',  there  are  some  internal  programmer 
messages  generally  used  for  implementation  checkouts  that  will  not  have 
message  numbers.  Users  will  see  these  messages  only  if  he  has,  (1)  turned  on 
special  programmer  debug  switches  (see  table  7-1,,  or  (2)  some  data  or 
program  problem  has  occurred.  In  either  of  these  cases,  the  AFMSMET 
programming  staff  should  be  contacted. 
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Contact  programmer  for  problem  resolution. 


SIMULATION  MAIN  MODULE  DIAGNOSTIC  MESSAGES 
(TYPE:  F=FATAL,  W=WARNING) 
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APPENDIX  D 

POST  PROCESSOR  DIAGNOSTICS 


The  post  processor  diagnostics  currently  are  not  sequentially  numbered  and  listing 
them  in  a  format  such  as  in  Appendix  B  and  C  is  currently  not  feasible.  However, 
the  messages  that  do  print  are  generally  self-explanatory.  Therefore,  this  appen¬ 
dix  will  be  provided  at  a  later  date,  probably  with  th »  first  update  of  this 
publication. 


APPENDIX  E 


MAIN  MODEL  CORE  REQUIREMENTS  FORMULA  (HONEYWELL) 


The  sain  model  memory  approximation  formula  uses  the  Input  Data  Summary  at  end  of  Input 
Run  (printed  prior  to  the  dictionaries),  as  follows: 


Multiplier 


#  of  Resources 

#  of  Tasks  Names 

#  of  Nodes  (ignore) 

Control  Table  Entries 
Failure  Clocks 
Mission  Entry  Points 
Resources  Entering  Network 
NCRS  (*NSRPT) 

Search  Patterns  (NSRPT) 
Next  Higher  Failures 
Task  Resource  Requirements 
NOCL 


Plus  Data  from  Form  16 


#  of  Shifts  *  *  Resources  on  Shift 


Plus  Data  from  Form  10 


#  Operations  Headings 

#  A/C  Headings 

#  Personnel  Headings 

#  Part  Headings 

#  AGE  Headings 


»  of  Aircraft  Authorized  (UE),  all  -.ypes 
Above  Core  Requirements  (subtotal) 


+  Miscellaneous  Data 
+  Program 

+  Dynamic  Memory  Required 

5K  -  unconstrained,  4-15  K-constramed 
highly  constrained- 2EK 


Total  Required 


LCOM  II  MAIN  MODEL  CORE  REQUIREMENTS  FORMULA  (CDC) 


The  main  model  memory  approximation  formula  uses  the  Input  Data  Summary  at  end  of  Input 
Run  (printed  prior  to  the  dictionaries),  as  follows: 


Statistic  Value  Multiplier  Core  Reqd  (Decimal) 


#  of  Resources 

6.2 

#  of  Tasks  Names 

2 

*  of  Nodes  (ignore) 

0 

Control  Table  Entries 

2.5 

Failure  Clocks 

2.6 

Mission  Entry  Points 

2.5 

Resources  Entering  Network 

10 

NCRS  (*NSRPT) 

1 

Search  Patterns  (NSRPT) 

0 

Next  Higher  Failures 

.3 

Task  Resource  Requirements 

1 

NOCL 

1 

Plus  Data  from  Form  16 

#  of  Shifts  *  #  Resources  on  Shift 

3 

Plus  Data  from  Form  10 

#  Operations  Headings 

14 

»  A/C  Headings 

24 

»  Personnel  Headings 

20 

#  Part  Headings 

24 

#  AGE  Headings 

22 

Plus  Aircraft  Costs  ' 

♦  of  Aircraft  Authorized  (U£) ,  all  types  9 

Above  Core  Requirements  (subtotal)  - 

♦  Miscellaneous  Data  1,000 

♦  Program  54,000 

+  Dynamic  Memory  Required 

5K  -  unconstrained,  5-15  K-constrained, 

highly  consf.rained-25K  - 

Total  Required  Convert  above  no. 

to  Octal 


Appendix  G 

Performance  Summary  Report  Statistics 
Calculation  Methodology 


This  Appendix  provides  an  understanding  of  the  method  and  timing  of  statistic  calculations  for  the 
Performance  Summary  Report  (PSR).  The  LCOM  I  (OLD)  statistic  numbers  are  printed  on  the  PSR 
report  and  therefore  provide  a  ready  reference. 


A.  OPERATIONS  STATISTICS 


NUMBER  OF  MISSIONS  REQUESTED 


A  value  of  one  is  added  to  this  statistic  upon  each  entry  into  the  mission  starting  event  where  no 
mission  cancellation  has  been  scheduled.  If  cne  has  been  scheduled,  the  statistic  is  not  calculated.  It 
is  possible  that  the  mission  is  requested  in  one  report  period  and  flown  in  another,  particularly  if  the 
PSR  is  printed  during  the  time  period  when  sortie  scheduling  is  taking  place. 

OLD  NO.  2  NUMBER  ACCOMPLISHED 

A  value  of  one  is  added  to  this  statistic  by  the  mission  starting  event  after  it  has  been  determined  that 
the  minimum  number  of  aircraft  r  equired  to  fly  the  mission  is  ready.  It  is  possible  in  a  time  period  to 
have  more  missions  accomplished  than  requested,  particularly  if  the  PSR  is  printed  during  the  time 
period  when  sortie  scheduling  is  taking  place. 

OLD  NO.  3  PERCENT  ACCOMPLISHED 

This  statistic  is  the  -atio  of  the  number  of  mission?  accomplished  to  the  number  of  missions  requested. 
If  the  number  requested  is  zero,  no  statistic  is  calculated.  The  ratio  is  multiplied  by  100  to  display  a 
percentage  value.  The  statistic  is  calculated  at  the  time  of  the  PSR  output. 

OLD  NO.  6  NUMBER  OF  SORTIES  REQUESTED 

The  maximum  number  of  sorties  required  for  a  mission  is  added  to  this  statistic  upon  each  entry  into 
the  mission  starting  event  where  no  mission  cancellation  has  been  scheduled.  (Spares  are  not  included.) 
If  a  mission  cancellation  lias  been  scheduled,  the  statistic  is  not  calculated.  It  is  possible  that  the 
number  of  sorties  requested  is  calculated  in  one  report  period  and  the  sorties  flown  in  another, 
particularly  if  the  PSR  is  printed  during  the  time  period  when  sortie  scheduling  is  taking  place. 

OLD  NO.  7  NUMBER  ACCOMPLISHED 


In  the  mission  starting  event,  after  it  has  been  determined  that  a  mission  is  going,  a  value  of  one  is 
added  to  the  statistic  for  each  aircraft  that  is  to  fly  the  mission.  Spares  are  not  counted.  It  is  possible 
in  a  time  period  to  have  more  sorties  accomplished  than  requested,  particularly  if  the  PSR  is  printed 
during  the  time  period  when  sort'e  scheduling  is  taking  place. 

OLD  NO.  8  PERCENT  ACCOMPLISHED 

The  statistic  is  the  ratio  of  the  number  of  sorties  accomplished  to  the  number  of  sorties  requested.  If 
the  number  of  missions  requested  is  zero  (implying  io  sorties  were  requested)  no  statistic  is  calculated. 
The  ratio  is  multiplied  by  100  to  display  a  percentage  value.  The  statistic  is  calculated  at  the  time  of 
the  PSR  output. 

T1  NUMBER  OF  WEATHER  CANCELS 


At  the  time  of  the  weather  cancel,  the  maximum  number  of  aircraft  requested  is  added  to  the 
statistic.  Mission  tapering  rray  or  may  not  affect  the  statistic  depending  upon  user  data. 


NUMBER  OF  WEATHER  DELAYS 


At  the  time  of  the  weather  delay  the  maximum  number  of  aircraft  requested  is  added  to  the  statistic. 
Mission  tapering  may  or  may  not  affect  the  statistic  depending  upon  user  data. 


NUMBER  OF  ALERT  REPLENISHMENT 


At  the  time  of  the  alert  replenishment,  the  maximum  number  of  aircraft  requested  is  added  to  the 
statistic  depending  upon  user  data. 

G-2 


NUMBER  OF  ATTRITIONS 


and  the  aircraft  is  to  attrit,  a  value  of  1  is  added  to  the  statistic 


When  the  aircraft  actually  "flies' 


NUMBER  OF  RAM  REPAIRS 


and  the  aircraft  is  to  go  into  repair,  a  value  of  1  is  added  to  the 


When  the  aircraft  actually  "flies' 
statistic. 


NUMBER  OF  AIR  ABORTS  (TOTAL) 


When  the  aircraft  actually  "flies",  and  the  aircraft  is  to  abort,  a  value  of  1  is  added  to  the  statistic, 
A1  AVG.  AC  POST  SORTIE  TIME  (HRS) 


For  each  aircraft  that  reaches  end  of  network,  the  elapsed  time  between  the  end  of  its  sortie  tasks  and 
the  end  of  its  post-sortie  processing  is  added  to  a  total.  This  total  is  divided  by  statistic  A2  to  produce 
statistic  Al. 

A2  NO.  OF  POST-SORTIES  COMPLETED 


A  value  of  1  is  added  to  this  statistic  whenever  an  aircraft  completes  its  post-sortie  network, 
B.  AIRCRAFT  STATISTICS 

OLD  NO.  13  NUMBER  OF  AIRCRAFT  AUTH.  (EOP) 


The  current  authorized  level  of  aircraft  at  the  performance  summary  report  time  is  added  to  the 
statistic.  It  is  an  end  of  period  statistic. 

OLD  NO.  14  NUMBER  OF  AIRCRAFT  DAYS  AVAIL 


The  statistic  is  calculated  before  each  change  in  the  authorized  level  of  aircraft.  The  product  of  the 
current  authorized  level  and  the  length  of  time  at  that  level  is  added  to  the  statistic.  There  are  ten 
possible  places  this  can  occur. 

.  At  the  beginning  of  the  simulation  the  statistic  is  updated  to  initialize  collection  of  the 
statistic. 

.  The  statistic  is  updated  prior  to  disposing  of  an  aircraft  satisfying  a  backordered  "consume." 

.  The  statistic  is  updated  prior  to  adding  a  "generatecf  aircraft  to  the  system. 

.  The  statistic  is  updated  prior  to  disposing  of  an  aircraft  satisfying  an  immediate  "consume." 

.  The  statistic  is  updated  prior  to  disposing  of  an  aircraft  to  be  removed  from  the  system  by 
aircraft  attrition. 

.  The  statistic  is  updated  prior  to  removing  an  aircraft  from  the  system  because  of  RAM 
repair. 

.  At  PSR  time,  if  the  aircraft  is  on  a  shift,  the  statistic  is  updated  prior  to  reporting. 

.  At  PSR  time,  if  the  aircraft  is  not  on  a  shift,  the  statistic  is  updated  prior  to  reporting. 

.  Prior  to  shift  change,  the  statistic  is  updated  if  the  aircraft  is  on  a  shift. 

.  When  an  aircraft  returns  from  RAM  repair,  the  statistic  is  updated. 

OLDNa_15  PCT  SORTIES 

This  statistic  is  calculated  in  three  places. 


When  a  sortie  task  is  started,  the  increment  of  time  until  the  next  level  one  PSR  is  determined.  If  this 
increment  of  time  is  yeater  than  or  equal  to  the  length  of  the  sortie,  the  sortie  duration  (in  days)  is 
added  to  the  statistic.  If  the  sortie  will  extend  into  the  next  PSR  reporting  period,  the  increment  of 
time  until  the  next  level  one  PSR  is  added  to  the  statistic. 


When  a  sortie  task  is  completed,  the  length  of  time  that  the  sortie  was  flown  in  the  current  PSR  report 
period  is  calculated.  Also,  the  elapsed  time  since  the  last  report  is  determined.  If  the  time  since  the 
last  report  is  greater  than  the  time  flown,  no  data  is  collected  since  the  time  has  already  been  added 
(see  above  -  sortie  started  and  completed  in  same  report  period).  If  the  time  since  the  last  PSR  is 
equal  to  the  time  flown  in  this  PSR  report  period,  the  days  are  added  to  the  statistic. 

At  PSR  time,  the  statistic  value  is  converted  into  hours  and  is  stored  for  later  use.  The  stored  flying 
days  are  not  changed,  however. 

At  PSR  time,  the  aircraft  flying  days  is  divided  by  OLD  NO.  14,  and  multiplied  by  100  to  calculate  the 
percentage. 


START 


LAST  REPORT 


NEXT  REPORT 


Start 


At  S  I  ART  time,  the  value  D|,  D2  and  would  be  added  (in  days)  to  the  statistic. 


REMOVE 


LAST  REPORT 


NEXT  REPORT 


At  STOP  time,  only  D2  is  added  to  the  statistic. 

OLD  NO.  16  PCT  UNSCHEDULED  MAINTENANCE 
This  statistic  is  calculated  in  three  places. 

When  an  aircraft  is  at  end  of  network,  the  total  days  in  unscheduled  maintenance  is  added  to  tne 
statistic. 


At  PSR  time,  all  aircraft  in  all  sets  arc  updated  and  the  total  time  currently  spent  in  unscheduled 
maintenance  is  added  to  the  statistic. 

At  PSR  time,  the  total  number  of  aircraft  days  spent  in  unscheduled  maintenance  is  divided  by  the 
number  of  aircraft  days  available  and  multiplied  by  100  to  arrive  at  the  percentage.  It  must  be  pointed 
out  that  the  time  in  unscheduled  maintenance  is  calculated  according  to  a  statistics  hierarchy  of 
unscheduled  maintenance,  scheduled  maintenance,  NORS.  That  is,  if  the  aircraft  has  a  single 
unscheduled  job  in  process,  it  is  considered  in  unscheduled  maintenance.  It  is  only  in  one  of  the  other 
categories  if  it  has  no  inprocess  unscheduled  maintenance  tasks.  The  task  coding  scheme  identifies  the 
task  type. 

OLD  NO.  17  PCX  SCHEDULED  MAINTENANCE 

This  statistic  is  calculated  in  three  places. 

When  an  aircraft  is  at  end  of  network,  the  total  days  in  both  scheduled  and  unscheduled  maintenance  is 
added  to  the  statistic. 

At  PSR  time,  all  aircraft  in  all  sets  are  updated  and  the  total  time  spent  in  unscheduled  and  scheduled 
maintenance  is  added  to  the  statistic. 

At  PSR  time,  the  unscheduled  time  is  subtracted  from  the  total  and  the  result  is  divided  by  the 
aircraft  days  available  and  multiplied  by  103  to  arrive  at  the  percentage.  Once  again,  the  statistical 
hierarchy  is  followed. 

OLD  NO.  18  PCT  NORS 

This  statistic  is  calculated  in  five  places. 

When  a  scheduled  maintenance  task  is  started  and  there  are  no  scheduled  or  unscheduled  jobs  in 
process  and  the  aircraft  is  in  a  NORS  condition,  its  status  is  changing  from  NORS  to  scheduled 
maintenance.  The  time  (days)  the  aircraft  was  NORS  is  added  to  the  statistic. 

When  an  unscheduled  maintenance  task  is  started  and  there  are  no  scheduled  or  unscheduled  tasks  in 
process  and  the  aircraft  was  in  a  NORS  condition,  the  status  is  changing  from  NORS  to  unscheduied 
maintenance.  The  time  (in  days)  the  aircraft  was  NORS  is  added  to  the  statistic. 

As  an  aircraft  completes  a  job  considered  "NORS"  and  has  no  in  process  scheduled  or  unscheduled 
maintenance  or  any  NORS  jobs,  the  time  in  the  NORS  condition  is  added  to  the  statistic. 

At  PSR  time,  all  aircraft  in  all  sets  are  updated.  If  there  are  no  scheduled  or  unscheduled  jobs  in 
process  on  the  aircraft  and  there  are  some  NORS  jobs,  the  time  (days)  in  the  NORS  condition  is  added 
to  the  statistic. 

At  PSR  time,  the  total  NORS  time  is  divided  by  the  aircraft  days  available  and  multiplied  by  100  to 
arrive  at  the  percentage.  Once  again  the  statistical  hierarchy  is  followed. 

OLD  NO.  19  PCT  MISSION  WAIT  STATUS 

This  statistic  is  calculated  in  four  places. 

When  it  has  been  decided  that  a  mission  is  going  to  fly,  the  interval  of  time  that  aircraft  flagged  as  40 
or  60  have  been  waiting  is  added  to  the  statistic. 

When  a  mission  is  being  cancelled  for  the  aircraft  flagged  as  40,  the  length  of  time  (days)  that  they 
have  been  waiting  is  added  to  the  statistic. 
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At  PSR  time,  all  aircraft  in  all  sets  are  updated  and  the  total  time  the  aircraft  flagged  as  40  or  60 
have  spent  waiting  at  a  sortie  task  is  added  to  the  statistic. 

At  PSR  time,  the  total  mission  wait  days  is  divided  by  the  aircraft  days  available  and  multiplied  by  100 
to  arrive  at  the  percentage. 

OLD  NO.  20  PCT  SERVICE  &  MNT.WAIT 

The  number  of  aircraft  days  spent  in  service  and  maintenance  wait  is  calculated  as  the  residual  of  the 
total  aircraft  days  available  less  the  "OR"  (see  next  STAT)  days  less  the  sum  of  flying  days, 
unscheduled  maintenance  days,  scheduled  maintenance  days  and  mission  wait  days.  The  result  is 
divided  by  aircraft  days  available  and  multiplied  by  100  to  arrive  at  the  percentage. 

OLD  NO.  21  PCT  OPERATIONALLY  READY 

This  statistic  is  calculated  by  every  time  an  aircraft  is  placed  in  or  removed  from  a  cocked  set  or  avail 
set  of  aircraft.  The  total  time  the  aircraft  are  in  these  sets  is  the  pure  Operationally  Ready  (OR) 
time. 

At  PSR  time,  the  number  of  aircraft  days  in  pure  Operationally  Ready  (OR)  status  is  divided  by  the 
number  of  aircraft  days  available  and  the  result  is  multiplied  by  100. 

OLD  NO.  22  AVG  AC  POST  SORTIE  TIME  (HRS) 

At  the  end  of  network  processing  for  an  aircraft,  the  total  elapsed  time  from  end  of  sortie  task  to  end 
of  network  processing  is  added  to  the  statistic. 

At  PSR  time,  this  statistic  is  converted  into  hours  and  is  divided  by  the  number  of  aircraft  turnarounds 
to  obtain  the  statistic. 

OLD  NO.  23  AVG  NO.  OF  SORTIES/ AIRCRAFT/DAY 

In  mission  start  time,  the  statistic  is  incremented  by  one  for  each  aircraft  flying  a  mission. 

At  PSR  time,  the  statistic  is  divided  by  the  aircraft  days  available  to  obtain  the  average  number  of 
sorties  flown  per  aircraft  per  day. 

OLD  NO.  24  FLYING  HOURS 

As  discussed  under  OLD  NO.  15,  the  flying  days  is  converted  at  PSR  time  and  reported  as  flying  hoirs. 

T 7  NUMBER  OF  FCF  TASKS  FLOWN 

When  an  aircraft  starts  an  FCFTASK,  one  is  added  to  the  statistic. 

T8  AVG  AIRCRAFT  PRE-SORTIE  TIME  (HRS) 

When  an  aircraft  hits  the  sortie  task  for  the  first  time  for  a  mission  and  is  not  flagged  as  101  or 
smaller,  one  is  added  to  a  counter  and  the  elapsed  time  since  assignment  to  the  mission  and  reaching 
the  sortie  task  is  added  to  the  statistic.  The  average  is  computed  at  PSR  report  time. 


C.  PERSONNEL  STATISTICS 

OLD  NO.  27  MANHOURS  AVAILABLE  (100) 

This  statistic  is  calculated  in  four  places. 

At  PSR  time,  the  duration  (days)  since  the  last  shift  change  or  last  statistic  update  for  the  shift  for  a 
resource  on  a  shift  is  determined.  For  each  resource  on  that  shilt,  The  mandays  authorized  or  available 
is  calculated  and  added  to  the  statistic. 

At  PSR  time,  if  the  resource  is  not  on  a  shift,  the  authorized  level  times  the  level  one  reporting 
interval  is  added  to  the  statistic. 

At  shift  starting  time,  the  duration  (days)  since  the  last  shift  change  or  the  last  statistics  update  for 
the  shift  for  a  resoirce  on  a  shift  is  determined.  For  each  resource  on  that  shift,  the  mandays 
authorized  or  available  is  calculated  and  added  to  the  statistic. 

At  PSR  time,  the  statistic  is  converted  to  manhours  and  divided  by  100. 

At  PSR  time,  the  statistic  is  used  as  described  below. 

OLD  NO.  28  PERCENT  UTILIZATION 

At  PSR  time,  the  statistic  is  calculated  by  dividing  the  manhours  ised  (100)  by  the  manhours  available 
(100)  and  multiplying  by  100. 

OLD  NO.  29  MANHOURS  USED  (100) 

At  PSR  time,  the  statistic  is  calculated  by  adding  the  manhours  used  in  unscheduled  maintenance  and 
scheduled  maintenance  (all  divided  by  100).  This  implies  that  men  should  not  be  placed  on  other  types 
of  tasks  or  the  manhours  will  not  be  reported  prope-ly. 

OLD  NO.  30  PCT  UNSCHED  MAINTENANCE  OF  STAT  29 

This  statistic  is  calculated  in  four  places. 

As  a  job  ends  which  has  processed  an  unscheduled  task  type,  the  quantity  of  each  type  of  man  on  the 
task  times  either  the  duration  of  the  task,  if  completed  within  a  single  reporting  period,  or  the  portion 
completed  in  the  current  reporting  period,  is  added  to  the  statistic. 

At  PSR  time,  each  job  in  process  that  has  a  man  assigned  to  it  will  determine  the  amount  of  mandays 
expended  up  to  that  time.  If  the  task  type  is  unscheduled  maintenance,  the  mandays  are  added  to  the 
statistic. 

At  PSR  time,  the  mandays  are  converted  into  manhours  and  divided  by  ICO. 

At  PSR  time,  the  converted  hours  are  divided  by  toe  converted  total  hours  used  and  multip'ied  by  100 
to  arrive  at  the  percentage. 

OLD  NO.  3)  PCT  SCHED  MAINTENANCE  OF  STAT  29 
This  statistic  is  calculated  in  four  places. 

As  a  job  ends  which  has  processed  a  scheduled  task  type,  the  quantity  of  each  type  of  man  on  the  task, 
times  either  the  diration  of  the  task  if  started  and  completed  within  a  single  reporting  period,  or  the 
portion  completed  in  the  current  reporting  period,  is  added  to  the  statistic. 
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At  PSR  time,  at  performance  sum  nary  report  time,  each  job  in  process  that  has  a  man  assigned  to  it 
will  determine  the  amount  ol  mandays  expended  up  to  that  time.  If  the  task  type  is  not  unscheduled 
maintenance,  the  mandays  are  added  into  scheduled  maintenance  days  regardless  of  task  type. 

At  PSR  time,  the  mandays  are  converted  into  manhours  and  divided  by  100. 

At  PSR  time,  the  converted  hours  are  divided  by  the  converted  total  hours  used  and  multiplied  by  100 
to  arrive  at  the  percentage. 

NEW  NO.  PI  PCT  PRIME  OF  STAT  29 

This  statistic  is  calculated  in  four  places. 

As  a  job  ends  which  has  processed  as  a  scheduled  or  mscheduled  maintenance  type  task,  the  quantity 
of  each  type  of  prime  man  on  the  task  times  either  the  diration  of  the  task,  if  completed  within  a 
single  reporting  period,  or  the  portion  completed  in  the  current  reporting  period,  is  added  in  mandays 
to  the  statistic.  Note  that  a  type  7,  base  repair  tas<,  is  considered  as  unscheduled  maintenance  type 
task.  A  prime  resource  for  a  task  is  a  resource  defined  on  the  LOOM  II  Form  12  record.  If  a  resource 
is  not  a  prime  it  is  a  substitute.  A  substitute  is  any  general  substitute,  or  resources  defined  onlv  on 
LCOM  II  Form  12A  records.  1 

At  PSR  time,  for  each  job  in  process  that  has  a  man  assigned  to  it,  the  amount  of  mandays  expended 
during  the  summary  period  just  ending  is  determined.  If  the  task  type  is  scheduled  or  unscheduled 
maintenance  and  the  man  is  a  prime  resource,  the  mandays  are  added  to  the  statistic. 

At  PSR  time,  the  mandays  are  converted  into  manhours  and  divided  by  100. 

At  PSR  time,  after  the  converted  hoirs  of  stat  30  plus  stat  31  have  been  stored  in  stat  29,  the 
converted  hours  in  PI  is  divided  by  the  converted  hours  in  stat  29  and  multiplied  by  100  to  arrive  at 
the  percentage. 

NEW  NO.  P2  PCT  SUBSTITUTE  OF  STAT  29 
This  statistic  is  calculated  in  four  places. 

As  a  job  ends  which  has  processed  as  a  scheduled  or  unscheduled  maintenance  type  task,  the  quantity 
of  each  type  of  substitute  man  on  the  task  times  eithe-  the  duration  of  the  task,  if  completed  within  a 
single  reporting  period,  or  the  portion  completed  in  the  current  reporting  period,  is  added  in  mandays 
to  the  statistic.  A  substitute  resource  is  not  only  a  general  substitute  but  is  also  any  resource  defined 
on  LCOM  II  Form  12A  records  but  not  on  the  Form  1  ?  record  for  a  specific  task. 

At  PSR  time,  for  each  job  in  process  that  has  a  man  assigned  to  it,  the  amount  of  mandays  expended 
during  the  summary  period  just  ending  is  determined. 

If  the  task  type  is  scheduled  of  unscheduled  maintenance  and  the  man  is  a  substitute  resource,  the 
mandays  are  added  to  the  statistic 

At  PSR  time,  the  mar  days  are  converted  into  manhours  and  divided  by  100. 

At  PSR  time,  after  the  converted  hoirs  of  stat  30  plus  stat  31  have  been  stored  in  stat  29,  the 
converted  hours  in  P2  is  divided  by  the  converted  hours  in  stat  29  and  multiplied  by  100  to  arrive  at  the 
percentage. 

NEW  NO.  33  NUMBER  OF  MEN  DEMANDED 


This  statistic  is  calculated  in  one  place. 
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At  task  setup  time,  this  statistic  is  calculated  for  each  prime  man  retource  prior  to  scaning  their  on- 
hand  balances.  The  quantity  demanded  of  the  prime  man  for  ~  ie  'ask  is  addeo  to  the  statistic.  The 
statistic  is  updated  prior  to  the  determination  of  which  resources  will  be  passed  from  the  scan  process 
to  the  task  starting  process.  Therefore,  this  statistic  reflects  only  prime  resource  demands. 

NEW  NO.  P3  NBR  OF  MEN  DEMANDED  POST  SCAN 

This  statistic  is  calculated  or  used  in  two  places. 

At  task  setup  time,  for  each  type  of  man  (prime  or  substitute)  passed  from  the  on-hand  balance 
scanning  process  to  the  starting  mechanism  the  statistic  is  updated  ty  the  number  demanded. 

At  PSR  time,  this  statistic  is  used  in  the  calculation  of  percentages  for  stats  34,  35,  36,  and  37.  These 
statistics  are  calculated  only  at  initial  task  starting  time,  not  after  it  nas  been  backordered  and  a 
subsequent  restart  attempted. 

NEW  NO.  34  %  AVAIL  BY  OH.BAL.  OF  RESOURCE 

This  statistic  is  collected  in  two  places. 

At  task  setup  time,  the  portion  or  quantity  of  demands  for  men  that  can  be  satisfied  for  the  prime 
resource  from  the  on-hand  balance  is  calculated.  This  does  not  mean  that  the  task  requesting  the 
resources  will  necessarily  start. 

At  PSR  time,  the  statistic  is  divided  by  the  number  of  men  demanded  and  multiplied  by  100  to  arrive 
at  the  percentage. 

NEW  NO.  35  %  AVAIL  BY  GEN  SUBS  OF  RES 

This  statistic  is  collected  in  two  places. 

At  task  time,  the  portion  or  quantity  of  demands  for  men  that  car.  be  satisfied  for  the  prime  resource 
by  using  the  on-hand  quantities  of  substitute  resources  is  calculated.  This  does  not  mean  that  the  task 
requesting  the  resources  will  necessarily  start. 

At  PSR  time,  the  statistic  is  divided  by  the  number  of  men  demanded  and  multiplied  by  100  tr  arrive 
at  the  percentage. 

NEW  NO.  36  %  AVAIL  BY  EXPEDITE 

This  statistic  is  calculated  in  two  places. 

At  task  setup  time,  the  quantity  of  men  demanded  which  could  not  be  provided  by  the  existing  on-hand 
balances  of  prime  and  substitute  resources,  but  that  can  be  provided  by  the  expedite  procedire  (unless 
preempted  by  future  demands),  is  calculated. 

At  PSR  time,  the  statistic  is  divided  by  the  number  of  men  demanded  and  multiplied  by  100  to  arrive 
at  the  percentage.  Note:  The  word  provided  (PROV)  in  the  title  should  more  appropriately  be 
AVAILABLE  (AVAIL). 

NEW  NO.  37  %  AVAIL  BY  PREEMPTION  PROCESS 


This  statistic  is  calculated  in  two  places. 


At  task  setup  time,  the  quantity  of  nr.en  demanded  and  not  provided  by  the  existing  on-hand  balances  of 
prime  and  substitute  resources,  but  tnat  are  provided  by  preempting  other  tasks,  is  calculated. 

At  PSR  time,  the  statistic  is  divided  by  *.he  number  of  men  demanded  and  multiplied  by  100  to  arrive 
at  the  percentage. 

OLD  NO.  38  PCT  DEMANDS  NOT  SATISFIED 


This  statistic  is  calculated  in  two  places. 

At  task  setup  time,  the  quantity  of  men  demanded  and  not  able  to  be  satisfied  by  any  of  the  above- 
mentioned  methods  is  calculated. 


At  PSR  time,  the  statistic  is  divided  by  the  number  of  men  demanded  and  multiplied  by  100  to  arrive 
at  the  percentage. 

OLD  NO.  39  OVERTIME  MANHO'JRS  USED  (100) 


This  statistic  is  calculated  in  two  places 


When  a  shift  change  occurs  and  men  are  to  be  remc  ved  from  the  simulation,  if  they  are  removed  via  an 
expedite  procedure,  the  time  in  days  remaining  to  end  of  the  expedited  task  times  the  quantity  of  men 
removed  by  expedite  is  added  to  the  statistic. 

At  PSR  time,  this  statistic  is  converted  into  manhours  and  is  divided  by  100. 


OLD  NO.  40  MANHOURS  PER  FLYING  HOUR 


At  PSR  time,  flying  days  is  first  converted  into  flying  hours.  The  statistic  is  calculated  by  dividing  the 
manhours  used  (OLD  NO.  29)  by  flying  hours  and  multiplying  by  100.  This  is  done  because  the 
manhours  are  divided  by  100  previously  and  the  quotient  must  be  adjusted.  It  must  be  pointed  out  that 
this  statistic  is  entirely  dependent  upon  the  portion  of  the  real  situation  that  is  actually  networked  and 
has  its  tasks  coded  properly.  It  can  o.Uy  be  interpreted  properly  as  "Simulated  Man  Hours  Per  Flying 
Hour  (MH/FH)." 


D.  SHOP  REPAIR  STATISTICS 


NO.  OF  REPARABLE  GENERATIONS 


This  statistic  is  the  sum  of  OLD  NO.  4  5  and  OLD  NO.  46  before  they  are  converted  into  percentages. 
OLD  NO.  45  PCT  BASE  REPAIR 
This  statistic  is  calculated  in  three  places. 

When  a  part  reaches  the  end  of  network  (returned  to  supply),  and  if  it  has  not  hit  a  depot  repair  task 
and  has  not  been  reported  as  a  reparable  generation  in  a  PSR,  it  is  reported  as  an  active  base  repair. 

At  PSR  time,  if  the  part  processing  disposition  has  not  been  previously  reported  and  has  not  hit  a  depot 
repair  task,  it  is  reported  as  an  active  base  repair. 

At  PSR  time,  the  percentage  is  calculated  by  dividing  the  current  value  by  the  number  of  reparable 
generations  and  multiplying  by  lfO. 


PCT  DEPOT  REPAIR 


This  statistic  is  calculated  in  three  places 


When  a  part  reaches  the  end  of  network  {returned  to  supply),  and  if  it  has  nit  a  depot  repair  task  and 
has  not  been  reported  as  a  reparable  generation  in  a  PSR,  it  is  reported  as  a  depot  repair. 

At  PSR  time,  if  the  part  processing  disposition  hat  not  been  previously  reoorted  and  has  hit  a  depot 
repair  task,  it  is  reported  as  a  depot  repair. 

At  PSR  time,  the  percentage  is  calculated  by  dividing  the  current  value  by  the  number  of  reparable 
generations  and  multiplying  by  100. 

When  a  part  hits  a  depot  repair  task,  a  depot  flag  is  set  to  1. 

Thus,  at  PSR  time,  one  can  have  parts  with  a  depct  flag  of  0,  i,  2,  3.  The  (2)  and  (3)  will  not  collect 
statistics  because  they  have  been  previously  reported.  The  (0)  and  (1)  will  be  reported  and  will  be 
changed  to  (2)  and  (3)  respectively.  At  the  time  when  parts  are  returned  to  supply,  their  depot  flag 
values  can  be  0,  1,2  and  3.  The  (2)  and  (3)  will  not  collect  statistics. 


AVERAGE  BASE  REPAIR  CYCLE 


This  statistic  is  calculated  in  two  places. 

When  a  part  is  returned  to  supply  (reached  end  of  network)  from  a  reparable  generation,  and  if  the  part 
was  processed  as  an  active  repair  (did  not  encounter  a  depot  repair  task),  the  elapsed  time  from  part 
generation  until  return  to  supply  is  added  to  the  statistic. 

At  PSR  time,  the  statistic  is  divided  by  the  number  of  reparable  generations  returned  to  supply  (see 
OLD  NO.  49). 


PCT  ACTIVE  REPAIR 


This  statistic  is  calculated  in  two  places. 

When  a  part  is  returned  to  supply  (reached  end  of  network)  from  a  reparable  generation,  and  if  the  part 
was  processed  as  an  active  repair  (did  not  ercounter  a  depot  tepair  task),  the  elapsed  time  that  the 
part  was  in  either  scheduled  or  unscheduled  maintenance  is  added  to  the  statistic. 


At  PSR  time,  the  statistic  is  divided  by  total  elapsed  time  from  part  generation  until  return  to  supply 
(OLD  NO.  47  before  calculating  the  average),  and  multiplied  by  100  to  obtain  a  percentage. 


PCT  WHITE  SPACE 


This  statistic  is  calculated  in  two  places. 

When  a  part  is  returned  to  supply  from  a  reparable  generation,  a  value  of  one  is  added  to  the  statistic. 
This  is  only  the  number  actually  returned  to  supply  and  does  not  necessarily  correspond  to  OLD  NO.  44. 

At  PSR  time,  this  value  is  used  to  calculate  average  base  repair  cycle.  Also  in  SHOPS,  the  percentage 
white  space  is  determined  by  subtracting  OLD  NO.  48  from  100.  In  reality,  this  statistic  represents 
the  portion  of  total  elapsed  time  that  a  part  processec  from  generation  until  return  to  supply  as  an 
active  repair  (did  not  encounter  a  depot  repair  task),  that  was  spent  not  processing  a  scheduled  or 
unscheduled  maintenance  task. 


OLD  NO.  50  NO.  OF  ITEMS  IN  REPAIR  (EOP) 


This  statistic  is  calculated  at  PSR  time.  It  ,s  the  total  number  of  parts  (reparable  generation) 
currently  processing  in  the  network  which  have  at  least  one  scheduled  or  unscheduled  task  in  process. 
Note:  STAT  Title  might  more  appropriately  be  "NO.  OF  ITEMS  IN  ACTIVE  REPAIR  (EOP)." 


OLD  NO.  31 


NO.  OF  ITEMS  BACKLOGGED  (EOF) 


This  statistic  is  calculated  at  PSR  tirre.  It  is  the  total  number  of  parts  (reparable  generation) 
currently  processing  in  the  network  which  have  no  scheduled  or  unscheduled  tasks  in  process. 

E.  SUPPLY  STATISTICS 

OLD  NO.  54  TOT  DOLLAR  INVEST  ( 1 000)  (EOP) 

At  PSR  time,  this  statistic  is  calculated  as  the  current  authorized  level  of  the  part  multiplied  by  the 
unit  cost  and  authorized  level  of  the  part  multiplied  by  the  unit  cost  and  is  added  to  the  current  value. 
It  is  then  divided  by  1000  to  reflect  the  cost  in  units  of  1000. 

OLD  NO.  55  FILL  RATE  PERCENT 

At  task  setup  time,  the  portion  of  demand  for  a  part  resource  that  can  be  satisfied  from  the  on-hand 
balance  of  the  prime  part  is  added  .o  the  statistic. 

At  PSR  time,  this  statistic  is  divided  by  the  number  of  parts  demand  id  (OLD  NO.  57)  and  multiplied  by 
100  to  arrive  at  the  percentage. 

OLD  NO.  56  NUMBER  OF  BACKORDER  DAYS 

This  statistic  is  calculated  in  six  places. 

At  task  setup  time,  the  difference  between  the  on-hand  balance  and  due-out  balance  for  parts  is 
calculated  when  the  part  is  on  a  task  which  is  starting.  If  the  on-hand  balance  cannot  cover  the  due- 
out  balance,  the  amount  not  covered,  multiplied  by  either  the  interval  of  time  since  the  last  statistic 
change  or  last  report  period  for  the  statistic,  is  added  to  the  statistic. 

When  a  part  is  returned  to  supply,  a  similar  calculation  is  performed. 

When  a  request  for  a  part  is  placed  in  the  backorder  i  breads,  a  similar  calculation  is  performed. 

When  a  part  resource  assigned  to  a  joo  is  removed  from  the  in-process  or  backorder  threads,  a  similar 
calculation  is  performed. 

At  shift  start-up  time,  where  resources  are  being  added  to  or  removed  from  the  system,  a  similar 
calculation  is  performed  for  all  part  resources. 

OLD  NO.  57  NUMBER  OF  UNITS  DEMANDED 

At  task  set-up  time,  for  each  part  demanded  on  a  task,  the  quantity  demanded  is  added  to  the  statistic. 

At  PSR  time,  this  statistic  is  used  to  calculate  the  fill  rate  as  well  as  the  percentages  discussed  below. 

Statistics  OLD  NO.  58  —  OLD  NO.  61  are  calculated  only  at  initial  task  starting  time,  not  after  a 
backorder. 

OLD  NO.  58  PCT  OFF-THL-SHELF 

At  task  starting  time,  the  portion  of  a  demand  for  a  part  that  can  be  satisfied  by  either  the  prime  or 
substitute  part's  ort-hand  balance  is  added  to  the  statistic. 

At  PSR  time,  this  statistic  is  divider'  by  the  number  of  parts  demanded  (OLD  NO.  57)  and  multiplied  by 
100  to  arrive  at  the  percentage. 


OLD  NO.  59 


PCT  EXPEDITED  REPAIR 


At  task  set-up  time,  the  portion  of  parts  demanded  which  could  not  be  provided  by  the  existing  on-hand 
balances  of  prime  and  substitute  resources,  but  .hat  can  be  provided  by  the  expedite  procedure,  is 
calculated. 

At  PSR  time,  this  statistic  is  divided  by  the  number  of  parts  denanded  (OLD  NO.  57)  and  multiplied  by 
100  to  arrive  at  the  percentage. 

OLD  NO.  60  PCT  PREEMPTION 

At  task  set-up  time,  the  quantity  of  parts  demanded  and  not  provided  by  the  existing  on-hand  balances 
of  prime  and  substitute  resources  but  that  are  provided  by  preempting  other  tasks  is  calculated. 

At  PSR  time,  this  statistic  is  divided  by  the  number  of  parts  demanded  (OLD  NO.  57)  and  multiplied  by 
100  to  arrive  at  the  percentage. 

OLD  NO.  61  PCT  DEMANDS  NOT  SATIS. 

At  task  start-up  time,  the  quantity  of  parts  demanded  and  not  able  to  be  satisfied  by  any  of  the  above- 
mentioned  methods  is  calculated. 

At  PSR  time,  the  statistic  is  divided  by  the  number  of  parts  demanded  (OLD  NO.  57)  and  multiplied  by 
100  to  arrive  at  the  percentage. 

OLD  NO.  62 

Not  calculated. 

OLD  NO.  63  NO.  OF  ITEMS  ON  BACKORDER 

The  quantity  of  an  item  which  is  on  backorder  at  the  time  a  P3R  is  produced.  At  PSR  time,  the 
difference  between  the  due  out  balance  and  the  on-hand  balance  is  calculated,  stored,  and  added  to  the 
statistic. 

F.  EQUIPMENT  STATISTICS 

OLD  NO.  68  TO.  DOLLAR  INVEST.  (1000)  (EOP) 

At  PSR  time,  the  current  authorized  level  of  the  resource  is  determined.  This  level  is  multiplied  by  a 
unit  cost  and  added  to  the  statistic.  It  is  an  end  of  period  snapshot  statistic. 

At  PSR  time,  this  statistic  is  divided  by  1000  before  printing. 

OLD  NO.  69  EQUIPMENT  HOURS  AUTH  (100) 

At  PSR  time,  the  collected  statistic  is  converted  into  hours  and  div'ded  by  /00. 

At  shift  start-up  time,  the  resources-days  authorized  on  the  current  shift  are  calculated  and  added  to 
the  statistic.  These  are  calculated  on  the  basis  ol  the  duration  of  that  shift  or  the  last  time  of  update 
of  that  shift's  statistics. 

At  shift  start-up  time,  if  the  resource  is  on  a  sh.ft,  the  resource  days  authorized  on  the  current  shift 
are  calculated  on  the  basis  of  the  duration  of  that  shift  or  the  last  time  of  update  of  that  shift's 
statistics. 

At  PSR  time,  if  the  resource  is  not  on  a  shift,  the  resource  days  are  calculated  using  the  level  one 
report  period  and  added  to  the  statistic. 


OLD  NO.  70 


EQUIPMENT  HOURS  .WAIL.  (100) 


At  PSR  time,  the  collected  statistic  is  converted  into  hours  and  divided  by  100. 

At  shift  start-up  time,  the  resource  days  authorized  for  the  resource  are  computed  by  multiplying  the 
resource's  current  authorized  level  by  the  elapsed  time  since  a  statistics  update  was  performed  or  the 
shift  was  started. 

At  shift  start-up  time,  if  the  resource  is  on  a  shift,  the  resource  days  authorized  for  the  resources  are 
computed  by  multiplying  the  resource's  current  authorized  level  by  the  elapsed  time  since  either  a 
statistics  update  or  a  shift  change. 

At  PSR  time,  if  the  resource  is  not  on  a  shift,  the  resource  days  are  calculated  using  the  level  one 
report  period  and  added  to  the  statistic. 

At  PSR  time,  the  statistic  is  used  to  calculate  OLD  NO.  71  and  OLD  NO.  72. 

OLD  NO.  71  PCT  USED-UNSCHED  MAINT 
This  statistic  is  calculated  in  three  places. 

As  a  job  ends  which  has  processed  an  unscheduled  task  type,  the  quantity  of  each  type  of  equipment  on 
the  task,  multiplied  by  either  the  duration  of  the  task  (if  started  and  completed  within  a  single 
reporting  period),  or  the  portion  completed  in  the  current  reporting  period,  is  added  to  the  statistic. 

At  PSR  time,  at  performance  summary  report  time,  each  job  in  process  that  has  equipment  assigned  to 
it  will  determine  the  equipment  days  expended  up  to  that  time.  If  the  task  type  is  unscheduled 
maintenance  the  equipment  days  are  added  to  the  statistic. 

At  PSR  *ime,  the  statistic  is  divided  by  OLD  NO.  70  to  arrive  at  the  percentage.  The  base  statistic  is 
then  converted  into  hours. 

OLD  NO.  72  PCT  USED-SCHED  MAINT 

This  statistic  is  calculated  in  three  places. 

As  a  job  ends  which  has  processed  a  scheduled  task  type,  the  quantity  of  each  type  of  equipment  on  the 
task,  multiplied  by  either  the  duration  of  the  task  (if  started  and  completed  within  a  single  reporting 
period),  or  the  portion  completed  in  tue  current  reporting  period,  is  added  to  the  statistic. 

At  PSR  time,  at  performance  summary  report  time,  each  job  in  process  that  has  equipment  assigned  to 
it  will  determine  the  amount  of  equipment  days  expended  up  to  that  time.  If  the  task  type  is  not 
unscheduled  maintenance  the  equ.pment  days  art  added  into  scheduled  maintenance  regardless  of  task 
type. 

At  PSR  time,  the  statistic  is  divided  by  OLD  NO.  70  to  arrive  at  the  percentage.  The  base  statistic  is 
then  converted  into  hours. 

OLD  NO.  73  PCT  UNUSED 

This  statistic  is  the  residual  value  of  100  minus  OLD  NO.  72  and  OLD  NO.  73.  It  represents  the 
percentage  of  unused  equipment  hours. 

OLD  NO.  70  NUMBER  OF  BACKORDER-DAYS 

This  statistic  is  calculated  in  six  places. 


At  task  set-up  time,  the  difference  between  the  on- hand  balance  and  due-out  balance  for  equipment  is 
calculated  when  the  equipment  is  on  a  task  which  is  starting.  If  the  on-hand  balance  cannot  cover  the 
due-out  balance,  the  quantity  not  covered  multip.ied  by  either  the  interval  of  time  since  the  last 
statistic  change,  or  last  report  period  for  the  statistic,  is  added  to  the  statistic. 

When  a  piece  of  equipment  is  returned  to  supply,  a  similar  calculation  is  performed. 

When  a  request  for  equipment  is  placed  into  the  backorder  threads,  a  similar  calculation  is  performed. 

When  an  equipment  resource  assigned  to  a  job  is  removed  from  the  iivprocess  or  backorder  threads,  a 
similar  calculation  is  performed. 


At  shift  start-up  time,  when  resources  are  being  added  to,  or  removed  from  the  system,  a  similar 
calculation  is  performed. 


At  PSR  time,  at  performance  summary  report  time,  a  similar  calculation  is  performed  for  all 
equipment  resources. 


OLD  NO.  75  NUMBER  OF  UNITS  DEMANDED 


. f 


This  statistic  is  calculated  or  used  in  two  places. 


At  task  set-up  time,  for  each  piece  of  equipment  demanded  on  a  .ask,  the  statistic  is  calculated. 

At  PSR  time,  the  statistic  is  used  to  calculate  the  various  percentages  discussed  below. 

Statistics  OLD  NO.  76  --  OLD  NO.  79  are  calculated  only  at  initial  task  starting  time,  not  after  a 
backorder. 


OLD  NO.  76  PCT  AVAILABLE 

At  task  start-up  time,  the  portion  of  a  demand  for  equipment  ‘hat  can  be  satisfied  by  either  the  prime 
resource  or  substitute  resources'  on-  hand  balance  is  added  to  the  statistic. 

At  PSR  time,  this  statistic  is  divided  by  the  number  of  pieces  of  equipment  demanded  (OLD  NO.  75) 
and  multiplied  by  100  to  arrive  at  the  percentage. 

OLD  NO.  77  PCT  BY  EXPEDITE 

At  task  set-up  time,  the  portion  of  equipment  demanded  which  could  not  be  provided  by  the  existing 
on-hand  balances  of  prime  and  sjbstitute  respurces,  but  that  can  be  provided  by  the  expedite 
procedure,  is  calculated. 

At  PSR  time,  this  statistic  is  divided  by  the  number  of  pieces  of  equipment  demanded  (OLD  NO.  75) 
and  multiplied  by  100  to  arrive  at  the  percentage.  Note:  The  word  PROV  in  the  title  should  be  AVAIL 
(available). 

OLD  NO.  78  PCT  PROV.  BY  PREEMPTION 

At  task  set-up  time,  the  quantity  of  equipment  demanded  and  not  provided  by  the  existing  on-hand 
balance  of  prime  and  substitute  resources,  but  that  are  provided  by  preempting  other  tasks,  is 
calculated. 


At  PSR  time,  this  statistic  is  divided  by  the  number  of  pieces  of  equipment  demanded  (OLD  NO.  75) 
and  multiplied  by  100  to  arrive  at  the  percentage. 


G-15 


PCT  DEMANDS  NOT  SATIS. 


At  task  start-up  time,  the  quantity  of  equipment  demanded  and  not  able  to  be  satisfied  by  any  of  the 
above-mentioned  methods  is  calculated. 


At  PSR  time,  the  statistic  is  divided  by  'he  number  of  pieces  of  equipment  demanded  (OLD  NO.  75) 
and  multiplied  by  100  to  arrive  at  the  percentage. 

OLD  NO.  80  EQUIP  HOURS  BACKLOG  (100)  (EOP) 

At  PSR  time,  the  remaining  task  time  multiplied  by  the  quantity  of  equipment  on  each  task 
backordered  for  an  equipment  resource  is  added  to  the  statistic. 

At  PSR  time,  the  statistic  is  converted  tc  hours  and  divided  by  100. 


z*  t;  ite.  *®»  ns  m  -v*  m  **<  V  ^ 


'•*S?  iP^*  VT* 


^ttWaWISM  *‘ *•«**«*  .**5s*M!  ®W(S*|  *S*r 


‘fnmm&  ■  t\-,  jf.tr  &v*smf$trmn' 


x !?  ,.g.  «s  «w  ;.wia>  t**  c  m  w.; » . 


■Birt'ft  •-» 


«&£»»« 


'Bwm. 


NW/nOD 

mom 


LOGISTICS  COMPOSITE  MODEL  lco*<  h  -  simulation  model  inputs 
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system's  environment  from  studv  models  that  uermit  the  analysis  of  weapon  v. _ 


DD  ,ET»  1473  COITION  Of  I  NOV  Cl  II  OaiOLCTC 

J-l 


UNCLASSIFIED  ^ 

ICCURlTY  CL AlllfICATlON  Of  THIS  HAOC  (H* 


UNCLASSIFIED 


SECURITY  CLASSIFICATION  OF  THIS  PAOE(Wi«i  £>•(.  Bnltfd; 


19.  (continued) 

simulation,  supply  performance,  Systems  analysis,  systems  effectiveness,  weapon 
support. ’ 

20.  (continued) 

system  support  requirements.  The  LCOM  II  simulation  software  is  composed  of 
8  distinct  modules;  the  Input  Module  that  preprocesses  the  data,  the  Main 
Module  that  conducts  the  simulation  and  the  Post  Processor  Module  that  Includes 
several  Individual  post  processor  programs  providing  post  simulation  analysis 
and  data  displays.  All  modules  of  the  LCOM  II  simulation  software  are  described 
In  detail,  and  a  step  by  step  approach  for  preparing  the  input  forms  is  dis¬ 
cussed. 
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